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1  INTRODUCTION 


1.1  Background 

The  applicability  of  formal  specification  methods  to  Air  Traffic  Control  (ATC) 
systems  is  one  of  the  areas  of  the  research  being  undertaken  by  the  software 
engineering  section  of  the  ATC  Systems  Research  division  at  RSRE  for  the 
Civil  Aviation  Authority.  This  report  describes  an  investigation  into  the 
formal  specification  language  Z  and  its  applicability  to  radar  data  processing. 
The  main  thread  of  the  investigation  was  the  conversion  of  the  algorithmic 
specification  of  a  radar  processing  software  module  into  the  predicate-based 
language  Z.  To  do  this  has  involved  learning  about  Z  through  the  literature, 
attending  a  short  course  on  formal  methods,  discussing  problems  with 
experienced  RSRE  Z  users,  and  writing  the  formal  specification  which  was 
partly  validated  using  an  RSRE  Z  type  checking  tool. 

The  particular  software  module  used  in  the  conversion  exercise  is  called  the 
RADAR  PROCESSING  ACTIVITY  and  corresponds  to  the  initial  radar  plot 
processing  in  the  multi-radar  automatic  tracking  system  of  the  London  Air 
Traffic  Control  Centre  (LATCC)  radar  data  processing  system.  This  software 
was  chosen  for  the  investigation  because  it  represented  a  well  defined  piece  of 
ATC  software,  and  because  the  details  were  familiar  to  the  investigator  (the 
author).  The  informal  algorithmic  specification  of  the  activity  is  taken  from 
the  pseudo  code  (subsequently  referred  to  as  PDL,  Progam  Design  Language) 
developed  in  a  MASCOT  based  design  of  the  LATCC  tracking  system  given  in 
reference  1  and,  for  convenience,  reproduced  here  in  appendix  1. 

The  PDL  looks  much  like  the  high  level  programming  language  Pascal,  but  it 
is  not  too  precise  on  semantics.  For  example,  it  does  not  require  a  variable,  say 
X,  to  be  explicitly  given  a  type;  whether  X  is  INTEGER  or  REAL  has  to  be 
determined  from  supporting  text  or  by  context.  The  Z  language,  on  the  other 
hand  is  strongly  typed,  and  variables  must  be  given  types,  although  it  is  not 
necessary  to  give  details  about  a  type  if  these  details  are  not  required  -  a  name 
for  the  type  is  sufficient.  A  specification  in  Z  is  aimed  at  stating  what  is 
required,  whereas  the  PDL  defines  how  the  requirement  is  to  be  achieved. 

The  Z  specification  described  in  this  report  has  been  kept  deliberately  close  to 
a  one-to-one  correspondence  with  the  PDL  specification  since  this  eases  the 
problem  of  ensuring  the  Z  accurately  captures  the  requirement  of  the  radar 
processing  activity  as  represented  by  the  PDL;  it  is  intended  in  future  work  to 
abstract  away  from  the  implementation-like  specification  to  one  more 
suitable  for  inclusion  in  a  functional  requirements  document. 

1.2  Structure  of  Report 

The  main  body  of  the  report  is  concerned  with  the  development  of  the  formal 
specification  of  the  RADAR  PROCESSING  activity,  as  defined  by  the  PDL  in 
appendix  1,  and  is  tutorial  in  form.  Readers  wishing  to  see  the  Z  specification 
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in  a  non-tutorial  form  that  would  be  processed  by  a  typical  Z  type  checker 
should  refer  to  appendix  3. 

A  brief  description  of  the  RADAR  PROCESSING  activity  with  the  aid  of 
a  simple  dataflow  diagram  is  given  in  chapter  2.  This  is  followed,  in 
chapter  3,  by  a  brief  introduction  to  Z  which  should  help  in  understanding  the 
notation  and  concepts  which  are  likely  to  be  unfamiliar  even  to  experienced 
software  people.  In  this  introduction  a  Z  specification  of  the  dataflow  diagram 
of  the  RADAR  PROCESSING  ACTIVITY  is  developed.  It  should  be 
emphasized  that  the  main  specification  in  chapter  4  was  not  derived  from  this 
example  specification,  indeed  the  example  specification  was  produced  while 
preparing  this  report,  however  it  does  provide  an  embryo  of  a  method  for  top 
down  development  from  a  dataflow  diagram.  The  chapter  also  describes  some 
of  the  naming  conventions  used  in  Z  specifications. 

The  derivation  of  the  Z  specification  from  the  PDL  is  given  in  chapter  4.  A 
two  level  specification  approach  is  adopted  where  the  first  level  of  abstraction 
is  chosen  such  that  the  main  procedures  of  the  PDL  are  revealed  but  not 
detailed.  This  level  corresponds  to  a  level  slightly  more  detailed  than  that 
captured  in  the  dataflow  diagram  of  the  RADAR  PROCESSING  activity. 

The  second  level  of  the  specification  is  a  decomposition  of  the  first  level  in  a 
form  that  closely  matches  the  structure  of  the  PDL.  This,  together  with 
keeping  more  or  less  the  same  names  for  variables,  simplifies  the 
correspondence  checking  between  the  PDL  requirements  and  the  Z 
specification,  and  eases  the  understanding  for  those  already  familiar  with  the 
LATCC-like  radar  processing  programs. 

This  second  level  of  specification  presented  here  is  derived  from  that  which 
successfully  passed  through  an  RSRE  Z  type  checker  which  ensured  correct 
syntax  and  consistent  use  of  types.  The  presentation  is  in  tutorial  form  in  a 
top  down  manner. 

The  lessons  learnt  in  preparing  the  Z  specification  are  described  in  chapter  5. 
Chapter  6  lists  conclusions  and  discusses  the  possible  benefits  to  NATS  with 
proposals  for  follow  up  work. 


2  RADAR  DATA  PROCESSING  ACTIVITY 


The  general  requirements  of  the  activity  can  be  understood  with  the  aid  of  the 
data  flow  diagram  of  the  activity  shown  in  figure  1.  The  activity  takes  a  plot 
(which  will  be  either  target  or  weather  data)  from  the  input  buffer  (RADAR 
DATA  INPUT)  and  performs  either  target  or  weather  processing.  Target 
processing  involves  converting  the  plot  position  to  system  coordinates,  and 
deciding  if  the  plot  is  to  be  rejected,  or  to  be  used  for  display  only  purposes,  or 
to  be  sent  for  possible  correlation  with  tracks.  The  weather  processing 
determines  if  the  weather  data  is  to  be  used  for  display  purposes. 

The  RADAR  DATA  PROCESSING  activity  carries  out  the  initial  radar  plot 
processing.  It  takes  a  digitized  radar  plot,  which  has  come  from  one  of  a 
number  of  surveillance  radars,  from  an  input  buffer  and  checks  to  see  if  the 
plot  is  from  an  aircraft  target  or  if  it  corresponds  to  a  weather  strobe. 

If  it  is  a  target  plot  then  a  time  stamp  is  added  and  its  position  is  converted 
into  a  common  coordinate  system.  Subject  to  certain  criteria  which  are 
defined  later,  a  plot  is  then 

a)  thrown  away  as  not  required  (which  may  occur  during  coordinate 
conversion),  or 

b)  tentatively  correlated  with  a  track,  or 

c)  sent  for  display. 

If  it  is  a  weather  plot,  it  is  either 

a)  thrown  away,  or 

b)  sent  for  display. 

The  data  flow  diagram  of  the  activity  is  shown  in  figure  1  which  is  used  as  a 
model  for  the  Z  specification.  After  processing  a  plot,  the  activity  repeats  the 
processing  with  the  next  plot.  The  informal  specification  of  the  activity  is 
given  by  the  PDL  in  Appendix  1. 


Data  Horn  Diagram:  RADAR  PROCESSING  BCTIDITV 

Figure  1 
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3  THE  Z  LANGUAGE  and  NOTATION 


A  Z  specification  is  composed  of  a  mathematical  text  supported  by  a  natural 
language  description.  The  purpose  of  this  chapter  is  to  introduce  sufficient  Z 
notation  to  enable  the  Z  specification  of  the  radar  processing  activity  given  in 
the  following  chapter  to  ha  understood.  Further  details  on  Z  are  available  in 
references  1, 2, 8  and  9. 

A  small  Z  specification 

A  specification  of  the  data  flow  diagram  (figure  1)  provides  a  convenient  way 
of  introducing  some  of  the  terms  and  concepts.  First  the  data  areas  are 
specified  simply  by  listing  them  as  follows 

[  RRDAR-DRTfl-INPUT,  PLOT-DISPLRV-CHRNNEL, 

CORRELfiTION-ORTR-CHRNNEL,  reject_pl ot_channel , 
RRDRR_C0HFIGURflTI0N_P00L ,  TIf1E_P00L,  RfiDflR_PLOT  ]  . 

This  square  bracket  notation  serves  to  introduces  new  types  about  which  no 
more  detail  is  known  at  this  level  of  specification.  Note:  Integer  types  are 
assumed  to  be  in  the  standard  Z  library;  the  character  Z  is  used  to  denote  the 
type  integer  (positive,  zero,  and  negative)  and  M  to  denote  natural  numbers 
(non  negative  integers). 

The  Z  specification  is  completed  by  defining  the  three  radar  processing 
operations  in  terms  of  these  data  types.  One  way  of  doing  this  is  by  stating  the 
names  of  the  operations  with  their  input  and  output  types,  for  example 

TAKE:  RfiDflR_OflTR_INPUT  -**  RRDRR-PLOT 

however  a  slightly  more  complex  form  is  used  here  since  it  aids  the  tutorial: 

TAKE - 

I  take:  RfiDRR_DfiTfl_INPUT  RRDRR-PLOT 


this  states  that  TAKE  consist  of  a  (partial)  function,  given  the  same  name  in 
lower  case  for  convenience,  which  maps  RRDRR_DRTfl_ INPUT  to 
RRDRR-PLOT ,  The  other  operations  are  similarly  specified. 

TARGET-PROCESSING - 

target-processing  : 

TINEPOOL  x  RRDRR-CONFIGURRTION-POUL  x  RRDRR-PLOT  ■+» 
RRDRR-PLOT  x  CORRELRTION_DRTR_CHRNNEL  x 
PLOT-DISPLRV-CHRNNEL  x  rej ect_pl ot_channel 


this  states  that  TARGET-PROCESSING  contains  a  (partial)  function  which 
maps  the  pools  and  RRDRR_PLOT  to  the  channels  and  RRORR-PLOT,  and 


UERTHER-PROCESSING - 

weather-process i ng  : 

RflORR-CONFIGURRTION-POOL  x  RRDRR-PLOT  -+► 
RRORR-PLOT  x  PLOT_DISPLRV_CHRNNEL  x  rej ect.pl ot_channel 


this  is  similar  in  form  to  TARGET-PROCESSING . 

The  three  boxed  constructs  are  particular  forms  of  a  Z  structure  called  a 
schema.  Schemas  can  be  manipulated  with  a  set  of  rules  defined  in  the  Z 
schema  calculus  (reference  1).  Thus  in  terms  of  the  three  schemas  defined 
above  the  specification  of  the  data  flow  diagram  will  be  of  the  form 

(TRICE  and  TARGET-PROCESSING) or (TAKE  and  UERTHER-PROCESSING) 

which  indicates  the  alternative  paths  through  the  flow  diagram:  it  will  be 
seen  in  the  next  chapter  this  does  not  capture  exactly  what  is  required 

The  more  general  form  of  a  schema  contains  two  parts,  the  first  part  called  the 
signature  which  groups  together  declarations,  and  a  second  part  called  the 
’predicate'  which  enables  constraints  to  be  placed  on  the  variables  defined 
through  the  declarative  signature  part.  The  above  schemas  consist  of  only  a 
signature,  each  with  only  one  declaration;  the  predicate  part  is  omitted  as  no 
constraints  have  been  defined. 

Example  schemas 

An  example  of  a  more  general  schema,  not  connected  with  the  data  flow 
specification,  is  the  representation  of  a  simple  record  of  personal  identity 
number  with  limits  placed  on  the  values  of  the  identity  number 

P-IDENTITV - 

None  : TEXT 
Ident_No  :Z 


Ident_No  >0 
Ident_No  <1000000 


In  general,  the  upper  part  of  a  schema  contains  declarations  separated  by  line 
breaks  and/or  semicolons:  no  meaning  is  to  be  attached  to  order  of  the 
declarations.  The  lower  part  contains  predicates  (constraints)  which  are  also 
separated  by  line  breaks  and/or  semicolons:  the  predicates  so  separated  are 
considered  to  be  conjoined  (i.e.  the  'and'  is  implicit). 
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There  is  an  altemar'  e  horizontal  form  in  which  only  semicolons  are  used  as 
separators;  in  this  form  the  above  example  is 

P_I DEHT I  TV  S  [Nana  : TEXT ;  Ident_No  sZ  |ldent_No  >0;  Ident_No  <1000000  ] 

where  the  symbol  s  can  be  read  as  "is  defined  as",  and  the  vertical  line 
symbol  |  as  "such  that”. 

Schema  names  can  be  used  in  various  ways.  One  common  use  is  in  the 
declaration  part  of  another  schema,  for  example  in  the  personal  record 

P_REC0RD - 

P _ I  DENT  I  TV 

Salary  :Z 


Salary  >0 


is  equivalent  to 

P.RECORD - 

Name  :  TEXT 
Ident_No  :Z 
Salary  :Z 


Salary  >0 
Ident_No  >0 
Ident_No  <1000000 


Some  Naming  Conventions 

The  definition  used  in  specifying  the  data  flow  diagram  will  need  to  be 
refined  as  more  details  about  the  radar  processing  activity  are  obtained.  For 
instance  the  C0RRELRTI0N_DRTfl_CHRNNEL  will  be  modelled  as  a  variable 
called  Correl  at  i  on_0ata_Channel  which  is  a  sequence  of  RRDRR-PL0T:- 

CORRELRT I 0N_DRTfl_CHRNNEL - 

I  Correl at i on_Data_Channel :  eeq  RRDRR_PL0T 


or  equivalently 

C0RRELRTI0N_DflTfi_CHRNNElfi  [Orrtlat  ion_Dota_Chonnel :  seq  RRDflR_PL0T] 
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Many  operations  read  and/or  change  the  state  database.  Certain  conventions 
are  used  to  indicate  this.  A  as  the  first  character  of  a  schema  name  usually 
indicates  an  operation  may  read  and  change  the  indicated  part  of  the  state, 
while  E  or  s  indicates  the  operation  may  read  but  will  not  write  to  the  state. 

For  instance,  in  defining  an  operation  that  may  read  and  alter  the 
CORRELRTION_DRTfl_CHfiNNEL  buffer,  such  as  by  adding  a  plot,  it  will  be  found 
convenient  to  define  the  schema  ACORRELRT I ON_DRTfi_CHRNNEL  by 

ACORRELRTION_ORTfl_CHflNNEL - 

Cornel  at i on_Data_Channe1 ,  Cornel  at i on_Data_Channel ' 

: seq  RRDRR_PLOT 

here  the  dashed  character  '  is  used  to  indicate  the  state  after  an  operation. 
The  more  usual  way  to  define  this  schema  is 

ACORRELRT I ON_DflTR_CHRNNEL - 

I  C0RRELRTI0N_0flTR_CHRNNEL ,  CORRELRTION_DRTR_CHRNNEL 1 


The  characters  ?  and  !  are  also  appended  to  a  name  to  indicate  an  input 
variable  and  an  output  variable  respectively.  Names  are  case  sensitive  so  for 
example  TRICE  is  different  from  take. 


4  THE  Z  SPECIFICATION  (tutorial  form) 

4.1  Specification  Structure 

The  formal  Z  specification  is  based  on  a  model  in  which  the  activity  is  treated 
as  a  sequence  of  operations  which  access  the  state  variables  (the  database  as 
represented  by  the  data  Pools  and  Channels  shown  in  figure  1).  Note  the 
RRDRR-PLOT  is  a  local  data  storage  and  is  not  part  of  the  state. 
'reject_plot_channel'  is  a  'waste  bin'  and  is  only  used  explicitly  in  the 
example  specification  of  the  previous  chapter. 


4.2  First  Level  Specification 

The  first  level  specification  decomposes  the  operations  and  data  objects  of  the 
data  flow  diagram;  the  degree  of  decomposition  has  been  chosen  to  ensure 
that  the  procedures  in  the  body  of  the  Radar  Processing  activity  given  in  the 
appendix  are  revealed.  To  do  this  it  is  necessary  to  describe  the  structure  of  the 
data  areas  in  a  little  more  detail. 

The  channels  are  first-in  first-out  buffers  which  are  modelled  here  by 
sequences  of  plots.  The  RRORR_DRTR_ INPUT  channel  contains  a  sequence  of  plots 
of  type  SITE-PLOT  from  the  different  radar  sites,  which  in  Z  can  be  denoted  by 
seq  SITE-PLOT.  SITE-PLOT  can  be  thought  of  as  a  record,  the  details  of  which 
are  of  no  concern  at  this  level  of  the  specification.  The  types  of  plot  contained 
in  the  other  two  channel  buffers  are  DISPLRV-PLOT  and  RRDRR_PLOT 
respectively.  All  this  is  captured  in  the  Z  notation  by 

[SITE-PLOT,  RflDflR-PLOT,  DISPLRV-PLOT] 

which  introduces  three  new  types,  and 

RRDRR-ORTR-INPUT  s  [Radar_Data_Input :  seq  SITE-PLOT] 

CORRELRTION-DflTfl-CHRNHELS  [Correlat ion_Data_Channel : 

seq  RRDRR-PLOT] 

PLOT_OISPLflV_CHRNHEL  e  [Plot-Display  Channel: 

seq  DISPLRV-PLOT] 

which  defines  the  buffers  as  sequences.  Note  for  convenience  the  names  of 
the  sequences  are  the  capitalized  lower  case  text  ot  the  buffer  names,  although 
other  names  could  have  been  used. 

The  RfiDRR-CONFIPURRT  I  ON-POOL  contains  data  about  the  radar  sites  such  as  site 
position,  and  information  about  which  radar(s)  are  to  be  used  for  tracking  in 
different  geographical  areas  (called  radar  sort  boxes  -  RSB  for  short).  Details  of 
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the  pool  are  given  later.  This  pool  is  used  only  as  a  source  of  data  by  the 
RflDflR-PROCESSING  activity. 


The  Tlf1E_P00L  is  provided  to  enable  the  current  time  to  be  read. 

The  Operations 

The  first  part  of  the  activity  is  to  remove  a  SITE-PLOT  from  the  input  buffer 
and  decide  if  it  is  a  target  or  weather.  The  TRICE  operation  of  the  high  level 
specification  is  replaced  by  the  two  operations  TRICE  and  TRRGET:- 

TflKE  .  remove  site  plot  from  input  buffer  to  local  radar  plot  storage  area, 
TARGET  .  decide  if  local  radar  plot  is  target  or  not. 

If  it  is  a  target,  the  following  sequence  of  operations  on  the  local  radar  plot 
replaces  the  high  level  TARGET-PROCESSING  operation:- 

T I ME—STflnP  .  add  a  time  stamp  to  plot 

REG  I  STRATI  0N_C0LL  ItlflT  I  OH  .  systematic  position  errors  corrected 
R_RZ_F  I LTER  .  reject  plot  in  preset  r-az  bands 

COORD-CONUERT  .  position  to  system  coordinates 

RSB_ FILTER  .  plot  for  correlation  or  display. 

If  it  is  weather  then  the  high  level  UEATHER-PROCESSIHG  operation  is 
replaced  by:- 

UERTHER-F I  LTER  .  convert  for  weather  display  or  reject. 

Each  of  the  operations  is  defined  in  more  detail  later. 

The  RRDRR_PROCESSIHG  activity  is  defined  in  the  Z  notation  by 
RflDRR-PROCESSING  6 

(TRICE  and  TARGET)  >  TIf1E_STRf1P  »  REG  I STRRT 1 0H_C0LL  I HRT I OM 
R_RZ_FILTER  »  COORD-CONUERT  »  RSB-FILTER 

or 

(TRICE  and  not  TARGET)  »  UERTHER-FILTER . 


The  symbol  >  is  called  'piping'1  and  is  used  to  indicate  the  output 
components  from  one  operation  being  used  as  input  components  to  the 
subsequent  operation.  There  is  only  one  component  concerned  here,  namely 
the  local  radar  plot. 

The  logic  symbols  and,  or  and  not  are  denoted  in  Z  by  the  symbols  ~  , 
v  and  -i  respectively. 

It  is  not  considered  profitable  to  provide  any  more  details  on  the  individual 
operations  at  this  level  because  most  of  them  require  more  information  on 
the  data  structures  before  any  useful  meanings  could  be  specified. 

4.3  Second  Level  Specification 

The  degree  of  refinement  to  reach  the  second  level  of  specification  has  been 
such  that  the  resulting  Z  specification  corresponds  quite  closely  both  in 
structure  and  detail  to  that  of  the  defining  PDL  in  the  appendix.  Some 
extraneous  pieces  of  Z  have  had  to  be  added  in  order  that  the  the  Z  type 
checker  could  be  used.  The  particular  type  checker  used  did  not  have  REAL 
types  or  common  functions  such  as  SQRT  so  these  had  to  be  introduced  into 
the  "local  library"  by  the  following  Z  definitions:- 

t  RERL  ] 

(_*_),  (_+_),  (_/_)  :  (REALxRERL)-*»REfiL 

O-  : RERL  <-►  RERL 
COS,  SIN,  SQRT  : RERL  RERL 
TO-RERL  :Z  -»  RERL 
TO.INTEGER  : RERL  -♦  Z 

Note:  The  version  of  the  type  checker  used  did  not  allow  overloading  of 
operators,  so  for  example,  where  *  appears  in  this  specification  meaning 
multiplication  of  RERLs,  the  symbol  TinES  occurs  in  the  text  that  was  actually 
processed  by  the  type  checker.  The  Z  language  forbids  overloading  of  variables 
(reference  3)  but  is  less  clear  about  overloading  of  operators. 

To  avoid  having  to  define  too  many  other  operations,  the  types  DISTANCE  and 
TltlE  were  redefined  as  RERL  and  integer  respectively  by 

DISTANCE  e  REAL 
TINE  8  Z  . 


1  Piping  is  used  here  as  a  means  of  indicating  sequential  operation:  it  is 
assumed  that  if  the  specification  of  a  component  schema  in  a  pipe  is  not 
satisfied  then  the  pipe  is  terminated. 


Another  problem  with  Z  and  hence  with  the  type  checker  is  that  names  must 
be  defined  before  they  are  used.  Thus  to  the  type  checker,  the  specification  is 
presented  in  a  bottom-up  fashion  and  the  more  primitive  types  defined  first. 
Here  the  decision  has  been  taken  to  present  the  specification  in  a  top  down 
manner  so  that  detailed  definition  of  subcomponents  can  be  delayed. 

Types  for  radar  identities  and  secondary  radar  code  are  introduced  by 
[  RRDRR-ID,  SSRCODE  ] 
with  no  further  details  required. 


4.3.1  Refinement  of  the  CHANNELS 

There  is  no  refinement  of  the  data  channels,  however  for  later  convenience 
A  state  change  schemas  are  defined. 

[SITE_PL0T,  D I SPLfl V—PLOT ] 

RRDRR_DflTfl_INPUT - 

I  Rador_Data_Input :  seq  SITE-PLOT 


ARRDflR_ORTfl_IHPUT - 

I  RRDRR_DRTR_INPUT,  RRDRR_ORTfl_INPUT ' 


CORRELRTIOH_DRTR_CHRHHEL - 

I  Conrelat ion_Oata_ChanneI  :seq  RRDRR-PLOT 


ACORRELRTIOH-DRTR-CHRNNEL - 

I  CORRELRTIOH_OflTfl_CHRHHEL,  CORRELRTIOH_DRTR_CHRHHEL ' 


PLOT-DI SPLRV-CHRHHEL - 

j  Plot-Display-Channel  :seq  DISPLRV-PLOT 


APLOT_DISPLRV_CHRNHEL - 

I  PLOT-DI SPLRV-CHRHHEL,  PLOT_DISPLRV_CHRHHEL ' 


\ 


1  3 


4.3.2  Refinement  of  type  RRORR-PLOT 

RRDRR-PLOT  is  the  data  structure  type  of  the  local  radar  plot.  A  schema  for  this 
structure  can  be  obtained  immediately  from  the  corresponding  PDL  record, 

RRORR-PLOT - 

dessage-Length :  W 
Site-Data:  SITE-DRTR 
Timestomp:  T I HE 
Corrected_R,X, V:  DISTANCE 
Rsb_i d :  RSB-ID 
Plot-Statue:  PLOT-STRTUS 
Decay-Time:  TlflE 


SITE_DflTR,  RSB-ID,  and  PLOT-STRTUS  are  the  only  undefined  types.  In  the  PD  L 
SITE_DRTR  represents  either  target  or  weather  information  and  in  Z  this  can  be 
expressed  as  a  disjoint  union  of  types  TRRCET-DRTR  and  UERTHER-DRTR 

SITE-DRTR: :-Target_0ata<<TflRGET_0RTR>>|Ueather_0ata<<UERTHER_DRTfl>>, 

where 

:  :  ■  can  be  read  as  "is  a  new  basic  data  type  defined  by", 

|  denotes  an  alternative  and  can  be  read  as  or, 

<  <  >  >  bracket  the  domain  of  the  preceding  function;  for  example 

Target-Data  is  a  function  mapping  TflRGET-DflTfi  into  SITE-ORTfl.  The  inverse 
function  Target-Data'1  is  used  later,  for  example  to  check  if  the  Site-Data 
component  of  a  radar  plot  is  target  rather  than  weather  information. 

In  this  definition  TRRGET-ORTfl  and  UERTHER-DRTR  are  defined  by  the 
schema  types 

TRRGET-DRTR - 

deeeage-Length :  IN 

Recei ving_Radar_ID:  RRORR-ID 

Plot-Type:  PLOT-TVPE 

Range:  IS 

Azimuth:  IS 

SSR_Code :  SSRCODE 

Hode_C_Height :  IS 
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Tine-Delay:  TIME 
Run_Length:  RUN-LENGTH 
Squawk:  SQURUtC 

Plot-Type  «  HEATHER 

and 

UERTHER-DRTR - 

fleaaago-Length :  IN 
Receiuing_Rada:  _ID:  RRDRR-ID 
Plot-Type:  PLOT-TVPE 
Azimuth:  IN 
Start-Range:  IN 
Stop-Range:  IN 

Plot-Type  *  UERTHER 

Note  TRRGET-DRTR  is  constrained  to  be  not  of  UERTHER  Plot-Type,  and 
UERTHER-DRTR  is  constrained  appropriately. 

The  schemas  use  the  following  enumerated  types 

PLOT-TVPE: :-  SECONORRV-REINFORCED (SECONDRRV | PRIflflRV | UERTHER 
RUN_LENGTH::*  SHORT  |  LONG 
SQUHUIC::*  NONE  j  IDENT  |  EHERGENCV 

This  completes  the  specification  of  SI TE-DRTR,  leaving  RSB_IDand 
PLOT-STATUS  as  the  remaining  undefined  types  in  RRDRR-PLOT.  These  types 
are 

RSB-I D - 

|  Rsb-X,  Rab-V  :  IN 

PLOT-STATUS : : -  PREFERRED | SUPPLEMENTRRV | NULL 

Plot-Status  can  have  the  status  PREFERRED,  SUPPLEMENTRRV  or  NULL. 

As  the  specification  gets  more  concrete,  constraints,  such  as  limiting  Azimuth 
to  lie  in  the  range  0  to  4095,  can  be  added  into  the  schemas. 


This  pool  consists  of  three  main  components,  St  at  i  on_Dat  a  for  each  radar, 
and  radar_aort_box  radar  data  and  status.  The  corresponding  schema  types 
are  STATION-DATA,  RSB-OATA  and  RS B_ST A TUS.  The  number  of  radar 

stations  is  given  by  TOTAI _ STATIONS  and  is  kept  in  a  schema  called 

SVSTEfl-PARAflETERSI . 

RRDAR-CONFIGURAT I0N_P00L - 

STATION-DATA 

Station-Data  :  PSTATION-ORTA 

RSB-DATA 

RSB-STATUS 

SVSTEfl-PARAnETERSI 


“Station-Data  “TOTAI _ STRTIONS 


IP  means  the  power  set,  and  can  be  read  as  "a  set  of",  and  *  gives  the  size 
(number  of  distinct  elements)  of  the  set. 

SVSTEfl— PfiRRMETERSI - 

I  TOTAL-STATIONS  :IN 


The  components  STATION-DATA,  RSB-DRTA  and  RSB-STATUS  are  specified 
in  more  detail  below.  S  T  A  T 1 0  N_D  A  T A  is 

STATION-DATA - 

Radar_I0:  RADAR-ID 
X_Po«ition,  V-Position  : D I STANCE 
S»eep-Tine  :  TINE 
Range-Correction  :Z 
Rzieuth-Correct ion  :Z 
Rho_Theta_l1a9k  :  eeq  RHO_THETR_nRSK 
Ueather-tlaek  :9eq  LlfllTlNG-RANGE 
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*  Rho_Theta_f1a9k  ■  64 

*  Ueather-daek  ■  32 


Rho_Theta_f1ask  is  sequence  of  pairs  of  integers,  one  pair  for  each  of  64 
azimuth  sectors,  and  each  pair  is  of  type 

RHO_THETfl_tlfiSK _ 

I1ini»u»_Range  :IN 
naximum_Range  :M 


Ueather_f1ask  is  a  sequence  of  items,  one  item  for  each  of  32  azimuth  sectors, 
and  each  item  of  type 

L 1 11 1 T I HG—RRNGE - 

I  Limit  i  ng_Ronge  :  IN 


This  leaves  RSB_DRTfl  and  RSB_STRTUS  to  be  considered,  both  of  which  are 
64  by  64  arrays  in  the  PDL.  Here  they  are  modelled  by  simple  functional 
mappings: 

RSB_DRTfl - - - - — - — _ 

I  RSB_Dat a :  ( (1 . .64)  x  (1..64))  RSB_DRT 


where 

RSB_0RTfl [RSB_Pref erred : RROflR_IO; RSB_Supp 1 ement ary :RRDRR_ID]. 
The  notation  (1  . .  64)  is  a  convenient  way  of  representing  the  set  {1, 2, .  . ,  64}. 
Note  that  RSB_Dat  a ( i ,  j )  selects  the  i,j  th  element  of  RSB_Dat  a,  and 

RSB_Data(  i ,  j ) ,  RSB_Preferred  selects  the  RSB_Preferred  component  of 
the  i,j  th  element. 

Similarly  RSB_STRTUSis 

RSB_STflTUS -  -  _ _ 

I  RSB_Status  :  ((1..61)  x  (1..64))  -»  RSB-STRT 


where 

RSB-STRT  G  [StatU9_of-RSB:STRT;Supplei#entany..Statu9:SUP] 
STRT : : *  ORTR-REQUIREO  )  NO-ORTR 
SUP: ENABLED  |  DISABLED, 
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Notes  that  RSB_Status(  i ,  j )  is  the  i,j  th  element  of  type  (STRT ,  SUP).  Thus 
the  value  of  RSB_Stotus(  i ,  j ) .  Status_of_RSB  is  either  DRTR_REQUIRED  or 
NO-DRTR . 

TIMEPOOL 

This  a  general  ptirpose  operation  which  provides  the  current  time. 

TlhE-POOL - 

I  tine:  TIDE 


4.3.4  Refinement  of  Operations 

A  number  of  preset  parameters  are  required  by  the  operations  and  these  are 
gathered  together  in  the  schema  below 

SVSTEI1_PflRRf1ETERS2 - 

NERN-TRANSfl  I  SSI  ON-TINE :  TIME 
TUENTV-NM :  DISTANCE 
R_T0_Nf1_C0NUERS  I  ON  :  RERL 
N I N_RERS0NRBLE_f10DE_C  :IN 
NflX-REflSONfiBLE-NOOE-C  :IN 
DEFRULT_N00E_C  :IN 
NODE_C_Nn_CONUER$ION:  REAL 
RCP_T0_RR0IRNS  :  RERL 
N0_CVCLE_T0_D I SPLR V  :IN 

TAKE 

This  operation  takes  a  site_plot  off  the  RRDRR_DRTfl_INPUT  buffer,  reformats 
it  and  puts  in  the  working  space  called  plot. 

TAKE - 

ARRDRR_DRTfl_INPUT 

3 i t e _ p lot :  SITE-PLOT 

plot!  :  RRDRR-PLOT 

S i te_to_radarpl ot :SITE_PLOT-»RRDRR_PLOT 
Radar_Datci_Input  •  <> 

Radar_Oata_Input '  <site_plot>  ■  Radar_Dato_Input 
plot!  »  Slte_to_radarplot(  site-plot) 
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Here  A  R  R  D  A  R_D AT A_ INPUT  indicates  the  input  plot  buffer  may  be  read  and 
altered.  It  will  be  altered  by  removing  a  sit  e_p  I  ot  if  one  is  present,  i.e.  if  the 
buffer  Radar_Oata_Input  is  not  equal  to  the  empty  sequence  <  >.  The 
s  i  t  e_p  1  ot  is  taken  from  the  end  of  the  sequence;  this  is  ensured  by  stating 
that  the  Radar_0at  a_I  nput  sequence  before  the  operation  is  the  same  as  the 
sequence  at  the  end  of  the  operation  with  the  sit  e_p  1  ot  joined  ("")  to  it. 

The  function  S  i  t e_t o_radarp  1  ot  converts  the  S I TE-PLOT  format  into  the 
RADRR_PLOT  format.  The  details  are  not  too  important  here,  however  the 
variables  Ti  asst  amp,  Corrected_R,  X  and  V  are  not  given  values  at  this 
stage. 

The  output  variable  plot!  is  the  local  radar  plot  referred  to  in  earlier  text. 
TARGET 

This  operation  checks  that  the  variable  plot!  is  of  type  TARGET-PLOT. 

TARGET - 

plot!  :  RADAR-PLOT 

pi  ot ! . S i te_Data  c  ran  Target-Data 

ran  is  the  range  operator,  and  used  here  to  specify  all  the  possible  vales  of 
Target-Data.  Note  that  plot!  rather  pi  ot?  is  used  because  the  TARGET 
schema  is  used  to  check  the  output  variable  of  the  TAKE  schema  (see  section 
4.2). 

tide-sibhp 

T I  riE-STAflP - 

TlflE-POOL 

SVSTEH_PARRt1ETERS2 
plot?,  plot!  : RADAR-PLOT 

plot?. Site-Data  «  ran  Target-Data 
plot! .Tieeetaep  *  tiae  -  inplot?.Tl«e_Delay- 
tlERN-TRRHStl  I  SSI  0N_TIt1E 
■here  inplot?6Target_Data',(pl  ot? .  S  i  te_Data’/ 


The  input  plot  is  checked  to  ensure  that  it  is  of  type  TRRGET_DRTR  and  not 
UERTHER-DRTR.  Here  1 1  me  is  of  type  TIME  and  is  a  component  of 
TIHE_P00L,  and  flERN-TRANSfllSSION— TIDE  is  a  preset  system  parameter. 
Note  the  dot  notation  could  be  used,  as  in  S  i  te_Dat  a .  T  i  *e_Del  ay  (pi  ot?). 
The  predicate  S  i  te_Data(pl  ot?)  c  ran  TRRGET-DRTR 
is  redundant  as  far  as  the  whole  specification  is  concerned  since  it  will  be 
propagated  in  under  the  piping  operation  from  the  TRICE  schema.  However 

its  inclusion  here  ensures  the  T I  HE _ STOMP  schema  is  less  dependent  on  such 

knowledge.  Because  this  situation  occurs  with  other  operations  it  is 
convenient  to  rewrite  TIHE_STRt1P  as 


ATRRGET - 

I  plot?,  plot!  :  RflOflR-PLOT 


plot?. Site_Data  c  ran  Target-Data 


TIHE-STAMP - 

TIHE-POOL 

SVSTEn_PflRRnETERS2 

ATRRGET 


pi ot ! . T i meetamp  -  tine  -  i npl ot? . T i ne_De1 ay- 
f1EflN_TRfiNSniSSI0N_TinE 
■here  inplot?*Target_Dato',(plot?.Si te_Dota) 


A  slight  liberty  with  conventional  use  of  A  is  taken  since  p  1  ot  is  not 
actually  part  of  the  system  state,  but  can  be  thought  of  as  part  of  the  local 
Radar-Proceee  ing_flct  i  v  1  ty  state. 

REGISTRRTION-COLLinRTIQN 

This  operation  removes  the  small  systematic  errors  from  range  and  azimuth 
measurements.  The  output  azimuth  is  MODULO  4096  and  is  achieved  using 
the  Rz  i _eodu  1  o  function  which  is  not  defined  in  detail . 
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REG I  STRATI ON-COLL I RATION— 
RRDHR_CONFI GRAT I ON_POOL 
ATARGET 

sd:  STATION-DATA 
flzi_eodulo:2— *IN 


sd  «  Station_Oata 

sd.Radar-ID  *  inplot?, Receiuing_Radar_IO 
outplot! .Range  *  inpl ot?.Ronge+sd, Range-Correct  ion 
outplot! .Azieuth  *  Azi_«odulo(Az_cornected) 

■  here 

inplot?  6  Target-Data'Hplot?. Site-Data) 
outplot!  »  Target-Data'Kpl ot ! . S i te_Data) 

Az_conrected= i npl ot? . Az i suth  +  sd . Az i suth_Correct  i  on 


The  requirement  sd  c  St  at  i  on_0ata  ensures  that  the  radar  station  that  is 
being  referred  to,  is  actually  in  the  set  of  active  radar  stations  kept  in 
St  at i on_Data. 

B-flZ-EILTEA 

This  operation  rejects  a  plot  if  its  range  does  not  lie  between  limits  defined  in 
the  RADAR-CONFIGURATION-POOL.  Rejection  is  achieved  if  the  predicate  of 
the  schema  evaluates  to  false. 

R-AZ-FILTER - 

RRDAR-CONF I GURRT I0N_P00l 
ATARGET 

sd  :  STATION-OATA 


sd  c  Station-Data 

sd.Radar-ID  >  inplot?. Rsce i w lng_Radar_ID 
Inplot?. Range  >  Fi Iter.flinieue-Range 
inplot?. Range  <  Fi Iter. flax ieue_Range 
plot!  *  plot? 

■  here 

inplot?®Target_Data'1(plot?  .Si  te_Data) 
■ask_regionfiinplot?.flzieuth  div  61  +1 
F i 1 terfisd . Rho_Theta_flask(eask_reg i on) 
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The  underlying  assumption  is  an  azimuth  in  12  bits  (0-4095)  and 
mask_region  is  in  the  range  1..64. 

CQ0R0-C0HUERT 

This  operation  makes  a  correction  for  slant  range,  and  converts  the  plot 
position  to  system  coordinates,  i.e. 

C00RD-C0NU  *  si  ant_range_correct  I  on  »  coordinate-conversion 

No  slant  range  correction  is  made  to  plots  with  ranges  of  20  nautical  mile  and 
greater.  The  type  of  slant  range  correction  used  below  20  nautical  miles 
depends  on  whether  or  not  a  valid  secondary  radar  height  is  available. 

The  ModeC_OK  schema  is  used  as  a  predicate  (i.e.  as  boolean  procedure 
would  be  used  in  a  programming  language)  to  indicate  the  validity  of  the 
secondary  radar  height. 

ModeC_0K - 

SVSTEf1_PRRRf1ETERS2 

ATRRGET 


(  inplot?. Plot-Type  -  SECONDARY-REINFORCED 
v  inplot?. Plot-Type  -  SEC0N0RRV  ) 
inplot?.  f1ode_C-He  i  ght  l  niN_RERS0NRBLEJ10DE_C 
i  npl  ot  ?  .  f1ode_C_He  i  ght  i  11flX_RERS0NRBLE_t10DE_C 
■  here  i  npl  ot ?8Tar get_0at a'K pi  ot ?. S i te_Data) 


si ant_range_correct i on 
ATRRGET 

SVSTEn_PflRRf1ETERS2 

HodeC_0K 


r?  I  TUENTV-NH  and  crl  -  (r?  *  R_T0_Nn_C0NUERSI0N) 

V 

not(r?  i  TUENTV_Nn)  ^  tlodeC-QK  /s  cr|"convert1 

V 

not(r?  2  TUEMT V_ Nfl )  ^  not  (flodeC-OlO/scr  !“convert2 

■  here 

i npl otTSTarget-Data'Kpl ot? . S i te_Data) 
r?6T0_RERL( inplot?. Range) 
crjfipl ot ! . Correct ed_R 
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a~  (r?*R_TO_Nfl_CONUERSION) 

b»  ( TO-RERL (inplot?. riode_C_He i ght ) *n0DE_C_M1_C0NUERS I  ON ) 
c£  ( TO-RERL  (DEFflULT_f10DE_C)*HODE_C_N11_CONUERS I  ON) 
converts  SQRT(  (a*a)  -  (b*b)  ) 
convert 2fi  SQRT(  (a*a)  -  (c*c)  ) 


coord i not  e_conver3 i on - 

RRDRR-CONF IGURRTI 0N_F00L 
ATRRGET, 

SVSTE(1_PRRfl(1ETERS2 

3d:STRTI0N_0RTR 


sd  c  Station-Data 

sd.Radar-lD  =  inplot?. Rece i v i ng_Radar_ID 
plot! . X*  (cr?*SIN(az?) )  +  sd , X_Post i on 
p 1 ot ! . V«  (cr?*C0S(az?) )  +  ad.V_Posit ion 
■  here  i  npl  ot?£Target_Oata‘1(pl  ot? .  S  i  te_Data) 
cr?spl ot? .Correct ed_R 

az?«T0_RERL( i npl ot? . Rz i »uth)*RCP_TO_RRDIRNS 


RSB.FI LIE P 

This  operation  uses  the  x,y  coordinates  of  the  plot  to  find  the  corresponding 
radar  sort  box  coordinates.  If  the  plot's  radar  matches  one  of  the  radars 
(indicated  as  preferred  or  supplementary)  associated  with  the  sort  box  and  the 
appropriate  status  values  are  set  the  plot  will  be  put  on  the  correlation  buffer. 
If  no  match  occurs  the  plot  will  be  rejected.  If  a  match  occurs  but  the 
appropriate  status  values  are  not  set,  the  plot  is  sent  to  the  display  buffer. 

The  operation  consists  of  two  main  parts  as  defined  in 

RSB-FILTER  *  cal cul ate_rsb  >  rsb-status-f i 1  ter . 

The  rsb-statuo-f  i  1  ter  corresponds  to  a  complex  IF..ENDEF  statement  in 
the  main  body  of  the  radar  processing  activity  PDL. 

calculate_psb - 

RflORR-CONFIGURRT I ON-POOL 
ATRRGET 

TO-RSB-IO  :  RERL-»IN 
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plot! .Rsb-id.Rsb-X  ■  x? 

plot!  .Rsb_id.Rsb_V  ■  y? 

(plot! . PI ot_Status“PREFERRED  ^ 

pi otradar?«rsb_data ,RSB_Pref erred  ) 

V 

(pi  ot ! .  P 1  ot_Status“SUPPLEf1ENTRRY  /v 

pi otradar?“rsb_data . RSB_Suppl ementary ) 

(plot! .Plot_Status“HULL  ^ 

not  (plotradar?“r3b_data.RSB_Preferred)  />, 
not  (plotradar?«rsb_data.RSB_Supple»entary)  ) 

■here  i nplot ?«Target_Data‘1(pl  ot? . S i te_Data) 
x?«T0_RSB_I0(plot?.X  /  T0_RERL(16))+1 
y?«T0_RS8_I0(pl ot? . V  /  T0_RERL(1 6) )*1 
r3b_data=RSB_Data(x?,y?) 
pi ot radar ?s inplot?. Recei a i ng_Radar_ID 


T  o_Cor re  1  at i on - 

ACORRELRTION_ORTfl_CHRNNEL 
plot?  :RRDRR_PLOT 

Corre 1  at i on_Dat  a_Channe 1 '  « 

Cornel  at i on_Oata_Channel  ""  <plot?> 


To-D  i  splay - — — 

APLOT_DISPLRV_CHRNNEL 
plot?  :RR0RR_PL0T 

Display_Fore  :RRDRR_PLOT  -*♦  DISPLRV-PLOT 

Plot_0i3play_Channe1 '  ■  PIot_Display_Channel  ^ 

<Disp!ay_For«(p?ot?)> 
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rsb_status_f  i  Her - 

RflDfiR_CONFI GURflT I ON-POOL 
To_Correl at i on 
To_D i splay 


(To_Corre1 at i on  /s  RSB*on/v  p1ot?.Plot_Status“PPEFERRED) 

V 

(To_Correlat ion  a  RSB*on/\  plot?.Plot_Status-SUPPLEHENTHRV 
rsb-status? .Suppl emen tor y_S tat us*ENRBLED) 


(To_Disp1ay  ^  notlRSB^onJ^  plot?.Plot_Stotus»PREFERRED) 

V 

(To-Display  ^  not (RSB=on)^  plotT.Plot-Status^SUPPLEIIENTRRY 
a  rsb_st  at  us? . Suppl ementary_St at us*EHR BLED) 

■  here 

x?  «  plot?.Rsb_id.Rsb_X 
y?  «  pi ot? . Rsb_i d . Rsb_V 
rsb-status?  •  RSB_Status(x?, y?) 

RSB  ■  rsb-status? . Status_of_RSB 
on  £  DRTfl-REQUIREO 


Note:  Display- form  converts  the  plot  to  a  form  that  can  be  put  on  the 

display  buffer.  In  the  original  PDL,  a  plot  is  also  put  on  the  display  buffer  if  an 
attempt  to  put  it  on  the  correlation  buffer  fails  because  the  buffer  is  full:  that 
possibility  is  not  considered  here. 

HEATHER-FILTER 

The  first  part  decides  if  the  weather  data  is  needed  and  adjusts  the  values  if 
necessary.  The  second  part  sends  the  data,  after  setting  a  display  rate  parameter, 
to  the  display  buffer. 

UERTHER-FILTERP  i»eathcr_f i  l  ter  »  «eather_display 

The  main  objective  of  eeather_f i  Iter  is  to  ensure  the  values  of  the 
Start-Ronge  and  Stop-Range  components  do  not  exceed  a  specified  limit.  If 
St  op-Range  exceeds  the  limit  it  is  reset  to  the  limit.  The  preset  value  of  limit 
depends  both  on  the  radar  site  concerned  and  on  the  azimuth  sector  in  which 
the  plot  lies. 
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■eather_f i Iter - 

RRDflR_CONFIGURRTION_POOL 
plot?, plot!  :RRDRR_PLOT 
8d:STRTI0H_0RTR 


plot?. Site-Data  <  ran  Ueather_Data 
sd  c  Station-Data 

sd . Radar_ID“*eather? . Rece i o i ng_Radar_ID 
weather?. Start-Range  i  limit? 

(weather?. Stop-Range  £  1 imit?)v(weather! . Stop_Range“l  i m i t ? ) 
■  here  ■eather?SUeather_Data',(pl  ot? .  S  i  te_Data) 
■eatherjfiUeather-Data'Kpl ot ! .  S  i  te_Data) 

*ask?«iueather?  .  fiz  i  muth  diu  128  +  1 
1  i  n  i  t?S(ed .  Ueat  her_riask(mask?) ) . L  imi  t  i  ng_Range 


■eat  her_d i  sp  1  ay - 

RRDRR-COHFIGURRTION-POOL 

To_D i spl ay 

plot!  : RRDRR-PLOT 

sd : STRTION-DRTR 

SVSTEn_PRRHf1ETERS2 


pi ot? . S i te_Data  <  ran  Ueather_Data 
sd  «  Station-Data 

sd . Radar_ID-«eather? . Rece i u i ng_Radar_ID 

plot!. Decay_T i me-HO_CYCLE_TO_DISPLRY*sd . Sweep_T i me 

To-Display 

■here  ■eather?fiUeather_Data',(pl ot? . S i te_Data) 


NO_CYCLE_TO_DISPLfiV  is  a  system  parameter. 
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5  DISCUSSION 


5.1  Learning  Z 

One  of  the  main  objectives  of  the  study  was  to  gain  experience  in  using  Z:  the 
other  being  to  provide  an  initial  assessment  of  Z's  applicability  to  Air  Traffic 
Control  systems.  Familiarity  with  set  theory  and  a  programming  language 
such  as  Pascal  should  enable  some  basic  understanding  of  Z  without  difficulty. 
The  author  attended  an  introductory  course  on  formal  methods  which 
included  a  small  amount  on  Z  and  followed  the  Alvey  funded  self-learning 
course  on  discrete  mathematics  and  specification  (reference  5).  British 
Telecom  (reference  4)  consider  that  to  become  proficient  at  using  Z,  an 
intensive  introductory  course,  an  understanding  of  the  underlying  discrete 
mathematics,  and  several  months  practical  experience  is  required. 

One  problem  in  learning  Z  while  trying  to  use  it,  is  judging  how  much  one 
needs  to  know  in  order  both  to  make  a  reasonable  start  on  a  specification  and 
finally  to  complete  it.  The  training  discussed  proved  to  be  sufficient  to  enable 
an  initial  Z  specification  to  be  produced.  This  initial  attempt  then  underwent 
a  number  of  corrective  and  restructuring  iterations.  The  most  significant  of 
these  came  as  a  result  of  a  partial  "walk-through”  with  Z  experts  from  CC1 
division  at  RSRE  and  by  using  their  Z-type  checker.  The  type  checker  proved 
to  be  an  invaluable  assistant  in  the  learning  process. 

One  consequence  of  not  being  experienced  in  Z  was  that  it  was  sometimes 
difficult  to  choose  the  appropriate  Z  constructs  in  which  to  express  well 
understood  requirements.  A  couple  of  examples  illustrate  the  problem:  How 
are  the  notions  of  sequential  operations  and  an  infinite  flow  control  loop 
expressed.  As  described  in  chapter  4,  the  sequential  operation  was  solved 
using  "piping"  operations;  the  infinite  loop  remains  a  problem. 

Fortunately  only  a  few  of  the  mathematical  symbols  peculiar  to  Z  were 
needed  in  the  specification  work,  but  even  so  initial  encounters  are  likely  to 
be  off-putting. 

5.2  Applying  Z 

The  approach  to  producing  a  Z  specification  of  the  radar  processing  activity, 
described  in  the  appendix,  was  the  simple  one  of  converting  each  PDL  data 
structure  and  each  PDL  procedure/function  in  turn  into  a  Z  schema.  Thus  the 
overall  structure  of  the  radar  processing  activity  remained  essentially 
unaltered,  resulting  in  a  state  based  specification  with  a  set  of  operations 
transforming  one  state  of  the  database  into  another.  The  actual  methods  for 
producing  the  Z  specification  were  dictated,  to  some  extent,  by  having  to  learn 
Z  while  producing  the  specification.  Small  chunks  of  the  PDL  were  selected  as 
exercises  in  Z,  until  it  was  believed  that  all  the  different  structures  used  in  the 
PDL  could  be  handled  with  confidence.  This  meant  that  some  of  the  level-two 
specification  had  been  completed  before  the  level-one  specification.  In 
practice,  it  was  found  easier  to  tackle  the  data  structures  first,  since  in  many 


cases,  it  was  easy  to  construct  a  Z  schema  with  a  simple  and  exact  one-to-one 
correspondence  with  a  PDL  data  structure;  indeed  many  of  the  Z  data  schemas 
look  like  (allowing  for  small  notational  differences)  Pascal  records.  The  only 
difficulties  encountered  were  in  representing  a  data  item  which  could  have 
different  pre-defined  structures  and  in  representing  a  square  array.  In  the 
former  case  a  Z  construct  for  a  disjoint  union  provided  the  solution.  In  the 
case  of  the  array  -  neither  Z  or  the  'standard'  Z  library  has  built  in  array  types  - 
'  a  sequence  of  sequences'  was  adopted  initially  but  this  was  changed  to  matrix 
type  when  the  mechanism  for  defining  generic  types  in  Z  was  better 
understood:  after  comments  from  CC1  division  a  much  simpler  mapping  (see 
the  schema  RSB-DATA  in  section  4.3.3)  was  adopted  for  this  report  that  also 
maintains  a  closer  correspondence  with  the  PDL.  Neither  difficulty  would  be  a 
problem  for  an  experienced  Z  user. 

In  converting  the  PDL  procedures  to  Z,  one  of  the  main  problems  was 
unraveling  the  nested  conditional  IF  statements.  The  basic  technique  used  to 
convert  these  statements  into  Z  was  to  replace  the  nested  statements  by  a 
sequence  of  simpler  IF  statements.  For  example 
IF  A  THEN  B  ELSEIF  C  THEN  D 
would  be  replaced  by 
IF  A  THEN  B 
IF  not  A  and  C  THEN  D. 

In  this  form  only  one  of  the  conditions  (the  term  after  the  IF)  evaluates  to 
true  so,  in  effect,  the  two  statements  are  'or-ed'  together.  The  Z  equivalent 
will  be  of  the  form 

(A  and  6)  or  (notft  and  C  and  0) 
or  using  mathematical  notation  (A  /\  B)  v  (->A  C  ^  D). 

Other  minor  problems  which  arose  included  that  of  finding  out  how  to  refer 
to  items  in  certain  complex  data  structures,  and  of  having  to  introduce  type 
conversion  routines  and  standard  mathematical  functions  because  these  were 
not  in  the  Z  library.  One  error  (of  omission)  -  was  found  in  the  PDL;  the  PDL 
to  calculate  radar  sort  boxes  refers  to  a  plot-status  of  NULL,  a  value  which 
had  not  been  defined. 

Although  not  part  of  the  main  exercise,  Z  was  also  applied  in  a  top  down 
approach  by  specifying  the  data  flow  diagram  of  the  radar  processing  activity. 


5.3  Tool  Support 

The  only  tool  support  used  during  the  development  of  the  first  version  of  the 
Z  specification  was  a  Macintosh  computer  -  bit  graphics,  mouse,  and  windows 
-  with  a  set  of  Z  fonts  accessible  to  all  Macintosh  word  processors  that  obey  the 
standard  operating  system  guide-lines.  This  has  been  the  only  tool  used  for 
document  preparation. 

Later  versions  of  the  specification  were  subject  to  a  syntax  and  type  checker 
developed  in  the  CC1  division  at  RSRE.  The  checker  was  written  in  Algol68 
and  ran  under  a  research  operating  system  on  an  ICL  Perq  computer.  Again 
the  computer  had  bit  graphics,  mouse  and  windows.  The  type  checker  could 
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handle  a  proper  Z  specification  consisting  of  both  English  text  and  Z 
mathematics,  although  only  mathematical  parts  of  the  radar  processing 
specification  were  entered. 

The  reliability  and  functionality  of  the  tool  were  good,  and  it  proved 
invaluable  during  the  specification  process.  Only  one  error  was  encountered 
in  the  type  checker;  it  accepted  a 'macro' clause  of  the  form  •hare  x#(ft*B) 
which  is  not  allowed.  A  few  irritations  were  caused  because  overloading  of 
operators  was  not  allowed,  for  example  since  the  symbol  >  had  already  been 
defined  as  applying  to  INTEGER,  another  name  had  to  be  used  to  mean  'greater 
than'  when  applied  to  REAL.  The  associated  Z  text  editor,  while  handling  all 
the  Z  notation  and  symbology,  was  very  awkward  to  use  on  some  of  its 
editing  operations  particularly  when  compared  with  text  editors  on  the 
Macintosh. 
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6  CONCLUSIONS 


This  initial  application  of  the  formal  specification  language  Z  to  an  Air  Traffic 
Problem  has  been  extremely  valuable  and  instructive.  Z  rather  than  VDM 
(the  other  leading  model-based  formal  specification  language  in  the  UK)  was 
chosen  because  there  was  experience  and  expertise  at  RSRE,  Z  appeared  to 
have  better  structuring  facilities  for  large  specifications,  and  the  available  tool 
support  seemed  marginally  better  (some  being  at  hand).  The  application 
involved  converting  a  Radar  Processing  program  based  on  the  one  used  in 
the  LATCC  multi-radar  processing  system  and  defined  by  an  algorithmic 
Program  Design  Language  (PDL). 

6.1  Using  Z 

Some  important  points  observed  while  learning  and  applying  Z  are  listed 
below. 

Learning  Z 

1  Formal  training  in  some  form  is  required  for  writing  Z  specifications. 

2  Having  experts  at  hand  is  almost  essential  for  a  beginner. 

3  Tool  support  is  invaluable. 

Converting  PDL  to  Z 

1  Some  techniques  and  guide-lines  were  established  for  converting  from  PDL 
toZ. 

2  Data  structures  were  usually  the  easiest  to  map. 

3  Z  requires  data  to  be  typed,  although  details  of  the  type  need  not  be  revealed 
unless  needed  in  subsequent  Z  specification. 

4  Declaration  of  standard  mathematical  and  type  conversions  are  explicitly 
required. 

5  Control  flow  achieved  by  the  Z  piping'  operation. 

6  Walk-throughs  essential  -  this  implies  at  least  more  than  one  person  is 
needed  to  complete  Z  specifications. 

7  Tool  support  invaluable. 

8  Since  the  PDL  did  not  explicitly  handle  concurrency,  there  were  no  problems 
in  this  area  with  the  Z. 

Tool  Support 

1  No  Z  syntax/ type  checkers  were  commercially  available  at  the  time,  only 
text  editors. 

2  A  commercial  text  editor  with  Z  fonts  on  a  Macintosh  computer  was  used 
for  document  preparation.  The  use  of  dot  matrix  printers  was  cumbersome 
and  very  slow  with  relatively  poor  quality,  although  a  laser  printer  was  used 
for  the  final  printings. 

3  A  syntax  and  type  checker  developed  and  owned  by  another  division  in 
RSRE  was  used.  This  is  a  research  tool,  although  a  more  portable  version  is 
under  construction. 

4  The  research  tool  used  did  not  support  top  down  development. 


5  A  Z  type  checker  has  been  produced  by  the  Alvey  FORSITE  project  but 
attempts  to  obtain  copies  during  this  work  and  subsequently  have  been 
unsuccessful. 

6  Since  completing  this  work,  two  Z  type  checkers  originating  from  the 
Programming  Research  Group  at  Oxford  have  been  mentioned  in  Z  bulletin 
boards,  one  programmed  in  the  functional  language  ML,  and  the  other  called 
FUZZ  which  processes  Z  specifications  written  in  the  type  setting  language 
Latex  for  SUN  and  IBM  PC. 


6 a  Benefits  To  NATS 

The  benefits  of  using  formal  methods  are  claimed  to  be 

1  Clear  thought  with  improved  ability  to  specify  with  precision  and 
conciseness. 

2  Improved  precision,  consistency,  unambiguity,  and  completeness. 

3  A  precise  notation  in  which  specifications  can  be  reliably  communicated  to 
others. 

4  The  use  of  refinement  techniques  to  produce  implementations  that 
accurately  satisfy  their  specifications  and  to  assist  in  validation  of 
requirements,  and  hence  enable  manuals  related  to  implementation  to  reflect 
the  specifications  accurately. 

5  The  use  of  animation  techniques  to  assist  in  the  validation  of  the  semantic 
aspects  of  specifications. 

6  A  basis  for  informal  and  formal  reasoning  and  analysis  about  correctness, 
resulting  in  detection  and  elimination  of  errors. 

These  benefits  are,  with  varying  degrees  of  importance,  relevant  to  various 
NATS  procurement  activities  from  analysis  and  requirements,  through 
contract  monitoring  and  acceptance  to  maintenance.  The  application 
described  in  this  report  addresses  the  areas  of  detailed  requirements  and 
design,  although  many  of  the  lessons  can  be  extended  to  other  phases  of  the 
life  cycle.  The  exercise  confirms  the  first  three  benefits  listed  above.  The  Z 
specification  is  clearer  and  more  precise  than  the  PDL  definition  on  which  it  is 
based.  It  is  a  better  base  for  a  requirements  specification  because  it  describes 
"What  is  required'  rather  than  'How  it  is  be  achieved'.  Thus  the  PDL  should 
be  thought  of  as  a  refinement  of  Z,  although  in  this  instance  the  WHAT  was 
obtained  by  reverse  engineering  from  the  HOW. 

At  least  for  the  particular  areas  of  requirements  and  design  covered  in  the 
exercise,  it  is  considered  formal  specification  could  be  of  value  to  NATS  in 
producing  a  better  rapport  with  contractors  through  increased  clarity  and 
precision  of  specifications  and  leaving  less  room  for  argument.  The  improved 
communications  should  also  increase  visibility  and  increase  confidence  in 
acceptance  of  deliverables.  The  resulting  use  of  precise  and  unambiguous 
specification  should  also  be  of  benefit  in  subsequent  maintenance. 
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The  benefits  of  validation  through  animation,  implementation  through 
refinement  techniques,  and  the  value  of  reasoning  methods  will  be  addressed 
in  subsequent  work. 

Application  of  formal  methods  is  in  general  hampered  by  the  training  needs 
and  the  availability  of  good  tools.  Training  and  tools  should  not  be  seen  as  a 
great  barriers  in  the  future,  since  good  software  engineering  courses  will 
include  formal  methods  and  tools  are  just  about  entering  the  market  place. 
Although  not  key  issues  in  the  work  reported,  consideration  needs  to  be 
given  to  where  formal  specification  methods  can  be  best  used  and  how  they 
are  to  be  integrated  into  the  other  system  development  methods  and  tools 
being  used.  One  possibility  is  to  use  Z,  or  similar  specification  language,  to 
specify  the  functionality  of  the  actions /processes  of  methods  using  data  flow 
diagrams;  this  approach  is  being  adopted  by  BAe  for  development  of  avionics 
software  (reference  6). 

Finally,  it  is  worth  noting  the  encouraging  claims  of  80%  reduced 
maintenance  effort,  250%  productivity  gains  and  a  sixfold  decrease  in  software 
integration  times  reported  in  the  NCC  video  course  on  'Towards  Formal 
Methods'. 


6.3  Future  Work 

Apart  from  the  example  of  a  Z  specification  of  a  data  flow  diagram,  which  can 
be  considered  as  an  embryonic  method  for  top  down  development,  the 
specific  Z  radar  processing  specification  given  here  is  more  design  than 
requirements  because  of  the  close  mapping  from  the  PDL.  The  next  stage  of 
the  work  will  be  directed  more  to  the  Requirements  phase.  A  more  abstract 
version  of  the  Z  specification  given  here  will  be  produced.  This  will  be 
followed  with  a  versions  that  will  make  use  of  the  knowledge  of  those 
Requirements  not  captured  in  the  specifications  derived  from  the  PDL  and 
will  be  closer  to  that  which  would  developed  in  a  top  down  approach. 
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A1  Program  Design  Language  definition  of  the  RADAR  PROCESSING 


INTRODUCTION 

This  a  slightly  shortened  extract  from  reference  1  (I049/TD.4  Dec86)  of  the 
design  of  the  Radar  Processing  Activitity  in  PDL.  Diagrams  and  the  PDL  of  the 
module  display  plot  have  been  excluded.  The  formats  of  relevant  Pool  and 
Channels  have  been  added. 


3.1.  RADAR  PROCESSING  ACTIVITY 


This  activity  carries  out  the  functions  of  multi-radar  processing  on  plot  data  received  from  the 
radar  stations.  A  number  of  masking  techniques  are  used  to  separate  out  data  which  is  not  required 
for  further  processing,  data  which  is  not  required  for  correlation  but  which  should  be  displayed  as 
plots  on  the  radar  screens,  and  data  which  is  required  for  attempted  correlation.  The  three  types  of 
data  are,  respectively,  discarded,  placed  into  the  Plot  Display  Channel  for  processing  by  the  Console 
Handler  subsystem,  or  placed  into  the  Correlation  Data  Channel  for  processing  by  the  Correlation 
activity. 

Two  main  masking  techniques  are  applied.  Firstly,  each  radar  station  has  associated  with  it  a 
geographical  mask  defining  the  area  of  coverage  of  that  station.  Plots  received  from  a  station  which 
fall  outside  its  area  of  coverage  are  discarded. 

Secondly,  the  airspace  is  divided  into  16  nautical  mile  squares,  known  ^s  Radar  Sort  Boxes  (RSB's). 
Each  RSB  has  two  bits  of  information  associated  with  it:  whether  da^  ,rom  that  box  is  required  for 
correlation,  and  whether  the  supplementary  radar  site  for  the  RSB  is  enabled.  The  information  is 
maintained  by  the  Tracking  activity  based  on  expected  track  positions  (if  returns  from  an  aircraft 
being  tracked  could  appear  in  a  particular  RSB,  that  RSB  is  enabled)  and  continuity  of  radar 
returns. 

Radar  processing  is  based  around  'radar  plot's.  These  are  instances  of  the  following  data  structure: 


Radar  Plot 

-  Message  Length  (RADAR  PLOT  LENGTH) 

-  Site  Data 

large!  Data  I  Waaitier  Data 

-  Timestamp 

-  Corrected  Range 

-  X  Coordinate 

-  Y  Coordinate 

-  RSB  ID 

-  RSBX 

-  RSBY 

-  Plot  Status  (PREFERRED  |  SUPPLEMENTARY) 

-  Decay  Time 
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(TARGET  DATA  MSG  LGTH) 


Target  Data 

-  Message  Length 

-  Receiving  Radar  ID 

-  Plot  Type 

-  Range 

-  Azimuth 

-  SSRCcde 

-  Mode  C  Height 

-  Time  Delay 

-  Run  Length 

-  Squawk 


(SECONDARY  REINFORCED  |  SECONDARY 
|  PRIMARY) 

(Rho) 

(Theta) 


(between  receipt  and  transmission  by  radar) 
(primary  only  -  SHORT  |  LONG) 

(NONE  |  IDENT  |  EMERGENCY) 


Weather  Data 

-  Message  Length 

-  Receiving  Radar  ID 

-  Plot  Type 

-  Azimuth 

-  Start  Range 

-  Stop  Range 


(WEATHER  DATA  MSG  LGTH) 

(WEATHER) 

(Theta) 


'Site  Data'  is  the  information  supplied  by  the  radar  stations,  while  the  rest  (much  of  which  is 
unused  in  the  processing  of  weather  data)  is  calculated  during  radar  processing. 
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RADAR  PROCESSING  ACTIVITY 


acquire  circular  channel  (RADAR  DATA  INPUT,  OUTPUT) 
acquire  circular  channel  (CORRELATION  DATA  CHANNEL,  INPUT) 

loop  while  TRUE 

Mfi  (RADAR  DATA  INPUT  CHANNEL,  radar  plot.site  data) 

If  radar  plot.site  data.plot  type  <>  WEATHER 
timestamp  (TIME  POOL,  radar  plot) 

radar  plot.decay  time  a  RADAR  CONFIGURATION  POOL.station  data[radar  plot.site 
data.receiving  radar  id]  .sweep  time 

apply  registration  and  collimation  correction  (RADAR  CONFIGURATION  POOL,  radar 

plot) 

apply  rho-theta  filtering  (RADAR  CONFIGURATION  POOL,  radar  plot,  result) 

If  result  <>  REJECT  PLOT 

apply  slant  range,  correction  (radar  plot) 

apply  coordinate  conversion  (RADAR  CONFIGURATION  POOL,  radar  plot) 
calculate  rsb  (RADAR  CONFIGURATION  POOL,  radar  plot) 

If  radar  plot.plot  status  =  PREFERRED 
or  (radar  plot.plot  status  =  SUPPLEMENTARY 

and  RADAR  CONFIGURATION  POOL.rsb  status[radar  plot.rsb  id. rsb  x, 
radar  plot.rsb  id.rsb  yj.supplementary  status  =  ENABLED) 
if  RADAR  CONFIGURATION  POOL.rsb  status[radar  plot.rsb  id.rsb  x, 
radar  plot.rsb  id.rsb  y  j.status  of  rsb  =  DATA  REQUIRED 
place  (CORRELATION  DATA  CHANNEL,  radar  plot,  result) 

If  result  =  FAIL 

display  plot  (PLOT  DISPLAY  CHANNEL,  radar  plot) 
end  if 
else 

display  plot  (PLOT  DISPLAY  CHANNEL,  radar  plot) 
end  if 
end  if 
end  if 

else 

apply  weather  filter  (RADAR  CONFIGURATION  POOL,  radar  plot,  result) 

If  result  <>  REJECT  PLOT 

radar  plot.decay  time  =  NO  CYCLES  TO  DISPLAY  *  RADAR  CONFIGURATION  POOLstation 

data[radar  plot.site  data.receiving  radar  idj.sweep  time 
display  Plot  (PLOT  DISPLAY  CHANNEL,  radar  plot) 
end  if 
end  If 

end  loop 


end  RADAR  PROCESSING  ACTIVITY. 
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Each  radar  plot  is  timestamped  as  the  first  stage  of  its  processing.  This  timestamp  is  calculated 
from  the  current  time,  the  delay  between  receipt  and  transmission  at  the  radar  station  (contained  in 
the  data  fro.  he  radar  station)  and  an  estimate  of  the  mean  delay  between  transmission  by  the 
radar  station  and  receipt  by  the  Radar  Processing  activity. 


module:  timestamp  (TIME  POOL,  radar  plot) 
read  current  time  (TIME  POOL,  time) 

radar  plot.timestamp  =  time  •  radar  plot.site  data.time  delay  -  MEAN  TRANSMISSION  TIME 

return 

'read  current  time’  is  a  standard  access  mechanism  of  the  TIME  POOL. 


1.2  Registration  and  Collimation  Correction 


The  range  and  azimuth  (rho,  theta)  values  of  each  radar  plot  are  corrected  for  any  alignment  errors 
which  may  have  been  detected  in  the  receiving  radar  station.  Correction  takes  the  form  of  the 
addition  of  correction  values  to  range  and  azimuth. 

Azimuth  values  are  expressed  in  units  of  ACPs  from  North,  where  4096  ACPs  make  up  a  circle. 
Range  is  expressed  in  units  of  1/16  of  a  nautical  mile. 


module:  apply  registration  and  collimation  correction  (RADAR  CONFIGURATION  POOL,  radar  plot) 


radar  plot.site  data.range  =  radar  plot.site  data. range  +  RADAR  CONFIGURATION 
POOL.station  data[radar  plot.site  data. receiving  radar  id]. error  data.range  correction 

radar  plot.site  data.azimuth  =  radar  plot.site  data.azimuth  +  RADAR  CONFIGURATION 
POOLstation  data[radar  plot.site  data.receiving  radar  id].error  data,  azimuth  correction 
If  radar  plot.site  data.azimuth  <  0 

radar  plot.site  data.azimuth  =  radar  plot.site  data.azimuth  +  4096 
else 

If  radar  plot.site  data.azimuth  >  4096 

radar  plot.site  data.azimuth  =  radar  plot.site  data.azimuth  •  4096 

end  if 
end  If 


return. 


Rho-Theta  filtering  is  used  to  reduce  the  processing  load  on  the  system  by  rejecting  as  many  as 
possible  of  the  plots  which,  for  a  given  radar,  are  from  neither  preferred  nor  supplementary  sites 
of  a  Radar  Sort  Box  (RSB). 

In  practice,  each  mask  consists  of  64  equal  azimuth  intervals  (of  64  ACP's),  with  the  minimum  and 
maximum  ranges  to  be  considered  for  each.  This  is  represented  within  the  system  as  a  series  of 
tables,  one  per  radar,  stored  in  the  RADAR  CONFIGURATION  POOL.  The  filtering  operation  consists 
of  a  simple  check  of  plot  range  against  the  range  limits  of  the  appropriate  region.  Plots  falling 
outside  the  range  limits  are  discarded. 


module:  apply  rho-theta  filtering  (RADAR  CONFIGURATION  POOL,  radar  plot,  result) 


mask  region  -  integer  (radar  plot.site  data.azimuth  /  64)  +  1 
if  radar  plot.site  data.range  <  RADAR  CONFIGURATION  POOL.station  datajradar 
plot.site  data. 

receiving  radar  id]. rho-theta  mask[mask 
region]. minimum  range 

result  =  REJECT  PLOT 

else 

If  radar  plot.site  data.range  >  RADAR  CONFIGURATION  POOLstation  datajradar 

plot.site  data. 

receiving  radar  id]. rho-theta  mask[mask 
regionj.maximum  range 

result  =  REJECT  PLOT 

else 

result  =  ACCEPT  PLOT 

end  if 
end  if 


return. 
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Slant  range  correction  involves  adjusting  plot  range  information  to  take  into  account  the  height  of 
the  aircraft  involved.  Slant  range  correction  is  not  applied  to  plots  with  a  range  of  greater  than  20 
nautical  miles,  as  the  correction  then  becomes  insignificant.  Two  types  of  slant  range  correction 
are  applied,  according  to  the  type  of  radar  return  concerned. 

Conversion  factors  are  incorporated  into  the  algorithm  to  give  the  corrected  range  in  units  of 
Nautical  Miles  (NM).  (N.B.  Rho  is  in  1/16  of  a  NM,  Mode  C  Height  is  in  feet.)  The  constant  DEFAULT 
MODE  C  HEIGHT  IN  NM  is  in  units  of  NM. 

module:  apply  slant  range  correction  (radar  plot) 

If  radar  plot.site  data.range  2  TWENTY  NM 

radar  plot.corrected  range  -  radar  plot.site  data.range  *  RHO  TO  NM  CONVERSION 

FACTOR 

else 

if  (radar  plot.site  data.plot  type  =  SECONDARY  REINFORCED 
or  radar  plot.site  data.plot  type  =  SECONDARY 

and  (radar  plot.site  data.mode  c  height  2  MIN  REASONABLE  MODE  C 
and  radar  plot.site  data.mode  c  height  s  MAX  REASONABLE  MODE  C) 
radar  plot.corrected  range  =  square  root  of  /square  (radar  plot.site  data.range  * 

RHO  TO  NM  CONVERSION  FACTOR)  / 
square  (radar  plot.site  data.mode  c  height  ’ 

FEET  TO  NM  CONVERSION  FACTOR)) 

else 

radar  plot.corrected  range  =  square  root  of  /square  (radar  plot.site  data.range  * 

RHO  TO  NM  CONVERSION  FACTOR)  / 
square  (DEFAULT  MODE  C  HEIGHT  IN  NM)) 

end  if 
end  if 


return. 

3.1.5  Coordinate  Conversion 

The  plot  data  received  from  the  radar  stations  contains  positional  information  in  the  form  of  range 
and  azimuth  values  calculated  in  relation  to  the  site  of  the  station.  These  must  be  converted  into  the 
system  of  axes  used  by  the  system  (x,y).  Trigonometry,  and  a  knowledge  of  the  (x,y)  coordinates  of 
each  raaar  station,  are  used  to  achieve  this. 


module:  apply  coordinate  conversion  (RADAR  CONFIGURATION  POOL,  radar  plot) 


degrees  =  radar  plot.site  data.azimuth  *  DEGREES  IN  AN  ACP 

radar  plot.x  coordinate  r  RADAR  CONFIGURATION  POOL.station  datajradar  plot.site 

data.receiving  radar  idj.x  position  +  (radar  plot.corrected  range  *  sin  (degrees)) 

radar  plot.y  coordinate  *  RADAR  CONFIGURATION  POOL.station  datafradar  plot.site 

data.receivingradar  idj.y  position  +  (radar  plot.corrected  range  *  CPS  (degrees)) 

return. 
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3.1.6 _ Calculate— RSB 


Radar  Sort  Boxes  (RSBs)  are  fixed  16  NM  squares  covering  the  FIR  in  a  grid  of  64  by  64  boxes. 

The  x  and  y  values  in  the  grid  of  the  sort  box  in  which  a  particular  plot  is  located  may  be  obtained  by 
a  simple  translation  of  the  plot  (x,y)  coordinates.  The  identity  of  preferred  and  supplementary 
radars  for  that  RSB  may  then  be  obtained  from  a  look-up  table  in  the  Radar  Configuration  Pool 
which  associates  RSBs  and  radar  stations. 


module:  calculate  rsb  (RADAR  CONFIGURATION  POOL,  radar  plot) 


radar  plot.rsb  id.rsb  x  -  Integer  (radar  plot.x  coordinate  /  1 6)  +  1 
radar  plot.rsb  id.rsb  y  »  integer  (radar  plot.y  coordinate  /  16)  +  1 
If  radar  plot. site  data.receiving  radar  id  =  RADAR  CONFIGURATION  POOL. rsb 
data[radar  plot.rsb  id.rsb  x,  radar  plot.rsb  id.rsb  y].rsb  preferred 

radar  plot.plot  status  =  PREFERRED 
else 

If  radar  plot.site  data.receiving  radar  id  =  RADAR  CONFIGURATION  POOL.rsb 
data[radar  plot.rsb  id.rsb  x,  radar  plot.rsb  id.rsb  y].rsb  supplementary 
radar  plot.plot  status  =  SUPPLEMENTARY 

else 

radar  plot.plot  status  =  NULL 

end  if 
end  If 


return. 
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Weather  map  messages  are  subjected  to  a  different  type  of  rho-theta  filtering  from  radar  target 
messages.  A  weather  rho-fheta  filter  mask  consists  of  32  equal  segments  (of  128  ACP's),  each  of 
which  has  associated  with  it  a  limiting  value.  Weather  map  messages  whose  range  start  value  is 
greater  than  the  limiting  value  are  discarded.  Those  whose  range  stop  value  is  greater  than  the 
limiting  value  have  their  range  stop  values  replaced  by  the  limiting  value.  Those  whose  range  stop 
value  is  less  than  the  limiting  value  are  accepted  unaltered.  Weather  rho-theta  filter  masks  are 
stored,  like  target  rho-theta  filters,  in  the  RADAR  CONFIGURATION  POOL 

Weather  map  messages  are  not  generated  for  every  sweep  of  the  radar,  thus  each  weather  map 
message  is  displayed  for  a  time  equivalent  to  MAP  DISPLAY  SWEEPS  sweeps  of  the  receiving  radar. 


module:  apply  weather  filter  (RADAR  CONFIGURATION  POOL,  radar  plot,  result) 


mask  region  «  inteoer  (radar  plot.site  data.azimuth  /  128)  +  1 
if  radar  plot.site  data.range  start  >  RADAR  CONFIGURATION  POOL.station  datajradar 
plot.site  data.receiving  radar  idj.weather  mask[mask  region], limiting  range 

result  =  REJECT  PLOT 

else 

If  radar  plot.site  data.range  stop  »  RADAR  CONFIGURATION  POOLstation  data[radar 
plot.site  data.receiving  radar  idj.weather  mask[mask  region].limiting  range 

radar  plot.site  data.range  stop  =  RADAR  CONFIGURATION  POOL.station  datajradar 
plot.site  data.receiving  radar  idj.weather  maskjmask  region]. limiting  range 

end  If 

result  =  ACCEPT  PLOT 

end  If 


return. 
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4.1.2  RADAR  CONFIGURATION  POOL 


The  Radar  Configuration  Pool  contains  the  information  on  radar  stations  and  Radar  Sort  Boxes 
(RSB's)  which  is  used  by  the  Radar  Processing  activity  in  the  filtering  and  processing  of  radar 
plots.  The  data  is  in  two  parts: 

a)  Radar  station  data.  For  each  radar  station,  data  is  stored  on  site  identity, 
position,  sweep-time,  error  correction  values  and  the  geographical  rejection  mask  filters  used  in 
initial  data  selection  processing. 

b)  Radar  Sort  Box  data.  For  each  RSB,  the  identity  of  the  preferred  and 
supplementary  radar  sites  for  that  RSB,  and  the  RSB  status  (whether  data  is  required  for 
correlation,  whether  the  supplementary  site  is  enabled)  are  stored.  The  RSB  status  information  is 
maintained  by  the  Tracking  activity  on  the  basis  of  expected  track  positions  and  continuity  of  radar 
returns. 

The  format  of  the  Radar  Configuration  Pool  is  as  follows: 


Radar  Configuration  Pool 

-  Control  Queue 

-  Station  Data  [1  ..TOTAL  STATIONS] 

-  Radar  ID 

-  X  Position 

-  Y  Position 

-  Sweep  Time 
•  Error  Data 

•  Range  Correction 

-  Azimuth  Correction 

-  Rho-Theta  Mask  [1..64] 

•  Minimum  Range 

-  Maximum  Range 

-  Weather  Mask  (1..32] 

-  Limiting  Range 

-  RSB  Data  (1.. 64,1. .64] 

-  RSB  Preferred 

-  RSB  Supplementary 

-  RSB  Status  [1.. 64,1. .64] 

-  Status  Of  RSB  (DATA  REQUIRED  |  NO  DATA) 

-  Supplementary  Status  (ENABLED  |  DISABLED) 
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A2  Z  Glossary 

Symbols  used  in  chapters  3  and  4: 


[  ] 
2 
N 


X 


seq 

A 


* 

? 

! 

» 


* 

<> 


« 

A 

V 


IP 


Introduces  new  types 

The  integers;  postitive,  zero  and  negative 

The  natural  natural  numbers,  non  negative  integers 

"of  type" 

Function  (partial) 

Function  (total) 

Relation,  i.e.  a  set  of  ordered  pairs 
Cartesian  product,  denotes  ordered  pairs 
"such  that" 

Conjunction,  "and" 

Sequence 

Indicates  the  associated  state  may  change 

Indicates  the  associated  state  does  not  change 

Denotes  variable  after  an  operation 

Equality 

Inequality 

Input  variable 

Output  variable 

'Piping'  operation 

Anonymous  generic  parameter 

"defined  as" 

"is  a  new  type  defined  as" 

Exclusive  or:  disjoint  union 
Domain  or  type  of  preceding  function 
Inverse  function 

Number  of  distinct  elements  in  set 
Empty  sequence 
Sequence  joining  symbol 
"is  a  member  of' 

Logical  and 
Logical  or 
Logical  not 

Power  set:  read  as  "a  set  of" 
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A3  THE  Z  SPECIFICATION 

1  Introduction 

This  appendix  gives  the  specification  of  the  RADAR  PROCESSING 
activity  in  a  non-tutorial  form.  The  formal  Z  parts  are  presented  in 
the  order  that  a  typical  type  checker  would  expect,  i.e.  definitions 
of  named  items  such  as  variables  and  schemas  must  be  given  before 
they  are  used.  The  supporting  English  text  has  been  kept  to  a 
minimum  to  help  keep  down  the  length  of  the  report;  normally  a  Z 
specification  would  be  expected  to  contain  a  full  description  of  the 
requirements.  The  specification  is  not  exactly  that  which  passed 
through  RSRE  type  checker  because  overloading  of  the  standard 
operators  such  as  '+'  has  been  allowed  here,  a  simpler  model  for 
arrays  than  the  one  put  through  the  type  checker  is  used,  and  some 
errors  may  have  been  introduced  by  having  to  re-type  on  a  different 
computer. 

2  Specification  Structure 

The  RADAR  PROCESSING  activity  carries  out  the  initial  radar  plot 
processing.  It  takes  a  digitized  radar  plot,  which  has  come  from  one 
of  a  number  of  surveillance  radars,  from  an  input  buffer  and  checks 
to  see  if  the  plot  is  from  an  aircraft  target  or  if  it  corresponds  to  a 
weather  strobe. 

If  it  is  a  target  plot  then  a  time  stamp  is  added  and  its  position  is 
converted  into  a  common  coordinate  system.  Subject  to  certain 
criteria  which  are  defined  later,  a  plot  is  then 

a)  thrown  away  as  not  required,  or 

b)  sent  for  correlation  with  a  track,  or 

c)  sent  for  display. 

If  it  is  a  weather  plot,  it  is  either 

a)  thrown  away,  or 

b)  sent  for  display. 

The  data  flow  diagram  of  the  activity  is  shown  in  figure  1  (see 
chapter  3)  which  is  used  as  a  model  for  the  Z  specification.  After 
processing  a  plot,  the  activity  repeats  the  processing  with  the  next 
plot.  The  informal  specification  of  the  activity  is  given  by  the  PDL  in 
Appendix  1. 

In  Z,  the  RADAR_PROCESSING  activity  structure  will  be  defined  by 
the  schema  following  expression  which  corresponds  to  the  data 
flow  diagram  in  figure  1: 

RADAR-PROCESSING  « 

(TRICE  and  TARGET)  »  TINE-STROP  »  REG1STRRTI0N-C0LL1  NATION  » 
R-A2-FILTER  >  COORO-CONUERT  »  RSB-FILTER 
or 

(TRICE  and  not  TARGET)  »  UERTHER-FILTER. 
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3  The  Z  Specification 
3.1  Local  Z  library 

Some  extraneous  pieces  of  Z  have  had  to  be  added  in  order  that  the 
the  Z  type  checker  could  be  used.  In  particular  "'EAL  types,  type 
conversions  and  standard  mathematical  functions  form  a  "local 
library" 


[  REAL  ] 


<_*_),  (_♦_),  (-/-)  :  (BEflLxRERL)— *RERL 

_i_  :  REAL  «-*  RERL 

COS,  SIN,  SORT  :RERL  -*  REAL 
TO-RERL  :2  -►  REAL 
TO-INTEGER  :RERL  2 


The  types  DISTANCE  and  REAL  are  redefined  for  ease  of  type  checking 

DISTANCE  s  RERL 
TINE  e  2 

3.2  Plot  Formats 

Types  for  the  plots  from  the  radar  sites  (from  the  RADAR  DATA 
INPUT  buffer  to  be  precise)  and  for  displaying  are  defined  by 

[SITE_PL0T,  DISPLAY-PLOT] 

and  types  for  radar  identities  and  secondary  radar  code  are 
[  RRORR-ID,  SSRCOOE  ] 

The  following  enumerated  types  occur  in  plot  messages 

PLOT-TYPE:  :■  SECONORRY-RE I NFORCEO)  SECONDARY  |PRINRRY|llEfiTHER 
RUN_LENGTH::-  SHORT  |  LONG 
SQURUK::-  NONE  |  I0ENT  |  EHERGENCV 

Plots  from  the  radar  sites  will  be  either  target  data  or  weather  data 
defined  by  the  following  record  schemas 

TRRGET-ORTR - 

Message-Length:  N 
Recei wing_Radar_ID:  RRORR-ID 
Plot-Type:  PLOT-TYPE 
Range:  IS 
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flzieuth:  M 
SSR-Code :  SSRCODE 
f1ode_C_He  i  ght :  IS 
Ti#e_Delay:  TIME 
Run_Length:  RUN-LENGTH 
Squawk:  SQURUK 


Plot-Type  •  UERTHER 


and 

UERTHER-ORTR - 

rieesage-Length:  IS 
Receiuing-Radar-10:  RRDRR-10 
Plot-Type:  PLOT-TVPE 
Rzinuth:  IS 
Start-Range:  IS 
Stop-Range:  IS 


Plot-Type  ■  UERTHER 


Note  TARGET-DATR  Is  constrained  to  be  not  of  UERTHER  and  UERTHER_DRTR  is 
constrained  to  be  of  type  UERTHER. 

Plots  are  taken  from  the  input  buffer  and  converted  into  a  local  plot 
format  RRDRR_PLOT  which  is  defined  below.  Radar  sort  box  identifiers 
and  plot  status  variable  are  required  and  these  are  given  by 

RSB-IO - 

I  Rsb_X,  Rsb_V  :  IS 


PLOT-STATUS : : ■  PREFERRED | SUPPLE11ENTRRV | HULL 

The  local  plot  format  has  to  cater  for  the  different  structures  of 
target  and  weather  data.  This  is  accomplished  by  defining  a  disjoint 
union  type 

SI TE _ DRTR : : “Target-Dot a<<TRRDET_DRTA>>|Ueather_Doto<<UERTHER_DfiTfi>>, 

where,  for  example,  Target-Data  is  a  function  mapping  TflRGET-DRTR  into 
S1TE-DRTR.  The  inverse  function  Target-Dot  o  ' is  used  later  to  check  if 
the  Site-Data  component  of  a  radar  plot  is  target  rather  than 
weather  information. 
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RflORR _ PLOT - 

tleesage-Length:  M 

Site-Data:  S I TE _ DAT  R 

Tieestaep:  TIME 
Correeted_R,X,V:  DISTANCE 
Rsb-id:  RSB-1D 
Plot-Status:  PLOT-STRTUS 
Oecay_Ti»e:  HUE 


3.3  RADAR_CONFIGURATION_POOL 

Tills  pool  consists  of  three  main  components.  Information  about 
each  radar,  radar  identities  associated  with  radar  sort  boxes,  and 
status  Information  about  the  sort  boxes.  The  corresponding  schema 
types  are  STRTlON-OflTfl,  RSB-DRTR  and  RSB-STRTUS.  The  number  of  radar 

stations  is  given  by  TOTfll _ STATIONS  and  is  kept  in  a  schema  called 

SVSTEN-PRRRnETERSI  • 

SVSTEn_PRRfit1ETERS1 - 

I  T0TRL.STRTI0NS  :N 


STRT 1 0N_0flTfl  contains  a  range-theta  mask  for  subsequent  sector 
filtering  of  plots  and  a  range  based  mask  for  subsequent  weather 
filtering.  Rho_Theta_riask  is  sequence  of  pairs  of  integers,  one  pair  for 
each  of  64  azimuth  sectors,  and  each  pair  is  of  type 

RH0_THETR_f1flSK _ 

flininun-Range 
t1axi»u«_Range  :IH 


Ueather-flask  is  a  sequence  of  items,  one  Item  for  each  of  32  azimuth 
sectors,  and  each  item  of  type 

LlfllTING-RRNGE - 

I  Lift! t i ng_Range  :N 


STRTION-DRTR - 

Rodar-IO:  RRDRR-ID 
X-Position,  V_Positlon  : DI STANCE 
Seeep_Ti»e  :  T I HE 
Range-Correct  ion  :  Z 
Rzieuth-Correct ion  :Z 
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Rho_Theta_t1ask  :  seq  RHO_THETR_nfiSK 
(leather-flask  :seq  L I  tl I T I HG—RRHGE 


*  Rho_Theta_t1ask  -  64 

*  Ueother-flosk  *  32 


This  leaves  RSB_DflTfl  and  RSB-STRTUS  to  be  considered,  both  of  which 
are  64  by  64  arrays  in  the  PDL.  Here  they  are  modeled  by  simple 
functional  mappings: 

RSB_DAT  A  [RSB_Preferred :RRDRR_ID; RSB_Supple»enlary : RR0RR-1D] . 

RSB-DRTR - 

I  RSB_0ata:  ((1..61)  x  (1..64))  -•  RSB-DRT 


and 

STRT : : •  DRTfl-REQUIREO  |  N0_DRTfl 
SUP::-  ENRBLEO  |  DISABLED. 

RSB-STRT  A  [Status_of_RSB:STRT;Supplei»entary_Status:SUP] 

RSB_STATU$ - 

I  RSB_St at  us  :  ((1..61)  x  <1 . .64))  -*  RSB-STRT 


RRDRR— CONFIGURATION-POOL— 


STRTION-DRTR 

Station-Data 

:  JPSTRTI OM _ DATA 

RSB-DRTR 

RSB-STRTUS 

SYSTEN-PflRfinETEfiSI 

*Stat ion_Data 

•TOTAL-STATIONS 

F  means  the  power  set,  and  can  be  read  as  "a  set  of’,  and  *  gives  the 
size  (number  of  distinct  elements)  of  the  set. 
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3.4  The  I/O  Channels 

The  data  channels  are  modeled  as  sequences: 

RAOAR-OATA-INPUT - 

I  Radar_Oato_Input :  seq  SITE-PLOT 


ARAOAR_DRTA_INPUT - 

I  RADAR-DRTA-INPUT,  RflDRR_DATA_INPUT ' 


CORRELAT lON-DATfLCHRNNEL - 

I  Correlat ion_Data_Channel  :seq  RADRR-PLOT 


ACORRELATION-DATA-CHANNEL - 

I  CORRELAT I ON_DATA_CHANNEL,  CORRELATION_DATR_CHRNHEL ' 


PLOT_OISPLAV_CHAHHEL - 

I  Plot_Display_Channe!  :seq  DISPLAY-PLOT 


APL0T_D I SPLRV_CHANN£l - 

I  PLOT_OISPLAV_CHANNEL,  PLOT_DISPLRV_CHRHHEL ' 


3.5  TIMEPOOL 

This  a  general  purpose  operation  which  provides  the  current  time. 

TIf1E_P00l - 

I  Use:  TIME 


3.6  Operations 

A  number  of  preset  parameters  are  required  by  the  operations  and 
these  are  gathered  together  in  the  schema  below 

SVSTEM-PRRRMETERS2 - 

nERN-TRRNSttl SSI  ON-TIME:  TIME 
TUENTV-HM:  DISTANCE 
R-TO-NM-CONUERSION  :  RERL 
MIN-REfiSONRBLE-HODE-C  :« 


\ 
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nAX_REAS0NABLE_!10DE_C  :N 
DEFRULT-flDDE-C  :N 
(10DE— C_Nf1_C0NUERSI0N :  REAL 
flCP_TO_RRDlflNS  :RERL 
NO-CVCLE-TO-DISPLAV  :« 


3.6.1  TAKE 

This  operation  takes  a  site-plot  off  the  RRDRR-ORTR-IHPUT  buffer, 
reformats  it  and  puts  in  the  working  space  called  plot. 

TAKE - 

ARADAR_OflTA_I  NPUT 
site-plot:  SITE-PLOT 
plot!  :  RADAR-PLOT 

S i te_t o_radarpl ot : SI TE_PL0T-»  RADAR-PLOT 


Radar_Data_Input  •  <> 

Radar— Oat a_Input '  ^  <site_ plot>  ■  Radar_Dota_ Input 
plot!  •  S i te_t o_rodarpl ol (  site-plot) 

It  will  be  altered  by  removing  a  site-plot  if  one  is  present,  i.e.  if  the 
buffer  Radar_Data_Input  is  not  equal  to  the  empty  sequence  <>.  The 
site-plot  is  taken  from  the  end  of  the  sequence;  this  is  ensured  by 
stating  that  the  Radar_Oata_Input  sequence  before  the  operation  is 
the  same  as  the  sequence  at  the  end  of  the  operation  with  the 
site_plot  joined  (•“)  to  it.  The  function  Site_to_radarpiot  converts 
the  SITE-PLOT  format  into  the  RRDRR-PLOT  format.  The  details  are  not 
important  here. 

The  output  variable  plot!  is  the  local  radar  plot  referred  to  in  earlier 
text. 

3.6.2  TARGET 

This  operation  checks  that  the  variable  plot!  is  of  type  TfiRGET-PLOT. 
target - 

I  plot!  :  RAOAR-PLOT 


plot!. Site-Data  c  ran  Target-Data 


ATRRGET - 

I  plot?,  plot!  :  RRDRR-PLOT 


plot?. Site-Data  c  ran  Target-Data 
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ran  is  the  range  operator,  and  used  here  to  specify  all  the  possible 
vales  of  Target-Data.  Note  that  plot!  rather  than  plot?  is  used  because 
the  TARGET  schema  is  used  to  check  the  output  variable  of  the  TAKE 
schema  (see  section  4.2). 

3.6.3  TIME_STAMP 

The  input  plot  is  checked  to  ensure  that  it  is  of  type  TARGET_DRTR 
and  not  UERTHER_DATA.  Here  time  is  of  type  TlflEand  is  a  component 

of  TinE-POOL,  and  OEflH _ TRAHS11I  SSI  0H_T  I  ME  is  a  preset  system 

parameter. 

TlttE_STAHP - 

TinE_P00L 

SVSTEI1_PARAf1ETERS2 

ATBBGET 


pi o*. ! . Ti eeetaep  *  time  -  inplot?,Tiee_Delay- 
HERN_TRRNSniSS10N_TIt1E 
■here  inpl  ot?*Target_Data‘'(plot?.Si  t e_Dat  a) 


A  slight  liberty  with  conventional  use  of  A  is  taken  since  plot  is  not 
actually  pan  of  the  system  state,  but  it  can  be  thought  of  as  part 
of  the  local  Radar  Processing  state. 

3.6.4  HEGISTRflTIOH-COLLIflflTIOH 

This  operation  removes  the  small  systematic  errors  from  range 
and  azimuth  measurements.  The  output  azimuth  is  MODULO  4096. 

REG  I STRRT I OH—COLL  IflRT  I OM - 

RADfiR-CONFIGRflTION-POOL 

ATRRGET 

ed:  STATION-DATA 
Rzi_modulo:2— *N 


ed  <  Station-Data 

ed,Rodar_ID  •  inplot?. Recei ving_Radar_ID 
outplotl. Range  *  inplot?, Range+sd, Range-Correction 
outplotl .Azieuth  ■  Rzi_eodulo(Rz_corrected) 

■  here 

inplot?  *  Target_Ooto',(pl ot?. Site-Data) 
outplotl  *  Target_Data''(plotl.  Site-Data) 

Az_correct edfi i npl ot ?. Az i»ut h  *  ed . Rz i »uth_Correct i on 
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The  requirement  sd  c  Stat  ion_Ooto  ensures  that  the  radar  station 
being  referred  to,  is  actually  In  the  set  of  active  radar  stations  kept 
in  Stat ion_Data. 


3.6.5  R_AZ_FILTER 

This  operation  rejects  a  plot  if  its  range  does  not  lie  between  limits 
defined  in  the  RflDRR-CQNF I  GURAT  i  oh_pool.  Rejection  is  achieved  if  the 
predicate  of  the  schema  evaluates  to  false. 

R_flZ_FILTER - 

RRDRR—CONF I GURflT I  ON-POOL 
ATflflGET 

sd  ;  STflTION-OflTfl 


sd  c  Station-Data 

sd.Radar_10  *  inplot?. Reeeioing_Radar_ID 
inplot?. Range  >  F  i  1  ter .  fli  n  i  suit-Range 
inplot?. Range  <  Fi  1  ter . flax i »uit_Range 
plot!  ■  plot? 

■  hers 

inplot?4Tanget_0ata',(pl  ot?.Si  te_Data) 
sask_region*inplot?.flzisuth  dio  61  +1 
F i 1 ter^sd. ftho-Theta-Hask(sask_reg i on) 


The  underlying  assumption  is  an  azimuth  in  12  bits  (0-4095)  and 
task-region  is  in  the  range  1..64. 


3.6.6  COORD.CONVERT 

This  operation  makes  a  correction  for  slant  range  and  converts  the 
plot  position  to  system  coordinates. 

HodeC-OK - 

I  SVSTEH_PflRflnETERS2 
ATRRGET 


(  inplot?. Plot-Type  ■  SECONDARV-REINFORCED 
v  inplot?. Plot-Type  *  SECONDflRV  ) 
inplot?.  flode-C-Height  1  f11N_REAS0NfiBLE_t10DE_C 
Inplot?. Node-C-He i ght  i  f1RX_REAS0NABLE_H0DE_C 
•hsrs  Inplot ?PTarget_Doto',(plot?.  Site_Oata) 


elant-range.correct ion- 
ATRRGET 

SVSTEH_PRRflf1ETERS2 

t1odeC_0K 


r?  i  TUENTV_Nt1  and  cr!  •  <r?  *  ft_T0_Nn_C0NU£RSI0N) 

V 

nol(r?  2  TUEHTV_Ht1)  /■,  HodeC_0K  /.  cr!»conyert1 

V 

not(r?  i  TUENTV-Nrt)  /s  not(l1od#C_0K)^cr!"conyer>t2 

•hart 

inplot?6Target_Data',(plot?.Si  te_0ata) 
r?8T0_RERL( inplot?. Rang#) 
er|8p lot!. Correct ed_R 
a*  ( r  ?*R_T0_Nfl_C0NUER$  I  OH ) 

b«  (T0_RERL(  inplot?. !1ode_C_Height)*n0DE_C_HH_C0MUERSI0N) 
cs  (TO_REflL(OEFflULT_!tODE_C)*(10DE_C_N!t_CONUERSIOH) 
conyertl®  SQRT(  (a*a)  -  (b*b)  ) 
conyert2®  SQRT(  (a*a)  -  (c*c)  ) 


coord i nat e_conyers i on - 

RflORR-CONFIGURRTION-POOl 

ATRRGET, 

SVSTEn_PRRRriETERS2 

sd:STRTIOM_DRTR 


sd  c  Station-Data 

sd.Radar_IO  »  i npl ot ? . Rece i uing_Radar_lD 
plotl.X"  (cr?*SIH(az?))  +  sd,X_Po»tion 
plotl.V-  (cr?*C0S(az?))  +  #d . V_Po» i t i on 
■hart  inplot?STarget_Data',(plot?. Si t e_Dat a) 
cr?#p lot?. Correct  ed_R 

az?8T0_RERU i npl ot  ? . Rz i ■uth)*RCP_TO_RRDIRNS 


COORD— COliU  8  #lant_range_eorrect  ion  »  coord inate_conwer#  ion 


3.6.7  RSB_FILTER 

This  operation  uses  the  x,y  coordinates  of  the  plot  to  find  the 
corresponding  radar  sort  box  coordinates.  If  the  plot's  radar 
matches  one  of  the  radars  (  Indicated  as  preferred  or 
supplementary)  associated  with  the  sort  box  and  the  appropriate 
status  values  are  set  the  plot  will  be  put  on  the  correlation  buffer.  If 
no  match  occurs  the  plot  will  be  rejected.  If  a  match  occurs  but  the 
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appropriate  status  values  are  not  set,  the  plot  is  sent  to  the  display 
buffer. 

The  operation  consists  of  two  main  parts  as  defined  in  the  schemas 
ca1culate_r9b  and  rsb_»totu9_f  i  Iter. 

The  r»b_statu9_fi  Her  corresponds  to  a  complex  IF..END1F  statement 
in  the  main  body  of  the  radar  processing  activity  PDL. 

calculate_r8b - 

RfiDflR_CONF I GURflTI ON-POOL 
ATRRGET 

TO-RSB-IO  :  RERL-»N 


p1ot|.Rsb_id.R9b_X  «  x? 

plot  I .R9b_i d. Reb-V  ■  y? 

(plot!.Plot_Statu9*PREFERRE0  ^ 

plotradar?"r9b_data, RSB-Preferred  ) 

V 

(plot ! .PI ot_Statu9-SUPPLEHENTRRV  * 

plot  radar ?«r8b_dat a.  RSB_Supp!eeentary) 

S' 

(p!ot!.PIot_Statu9*NULL  /■, 

not  <plotradar?“r9b_data.RSB_Preferred)  ^ 
not  (plotradar?«r9b_data.RSB_Supple»entary)  ) 

•here  inplot?8Target_0ata'’(plot?. Si te_Data) 
x?ST0_RSB_I0(plot?.X  /  T0_RERL(16))+1 
y?*T0_RSB_ID(pl ot? . V  /  T0_RERL(1 6) )+1 
r9b_data8RSB_Data(x?,y?) 
pi ot radar?* i npl ot ?. Reee i u i ng_Radar_10 


Operation  to  put  plots  on  the  correlation  and  display  buffers  are 
needed  and  given  by 

T  o_Corr e 1  at i on - 

ACORRELRTION-ORTfl-CHflNNEL 
plot?  : RRORR-PLOT 


Correlat ion-Oata-Channel'  ■ 

Correlot  lon_Oata_Channe!  <plot?> 


and 


A3. 11 


w 


To-Oi»play - 

APLOT-DISPLAV-CHANNEL 
plot?  : RflDfiR_PLOT 

D i spl ay_For*  : RA0AA_PL0T  -»  D1SPLAV-PL0T 


Plot_0isplay_Channe1 '  ■  Plot_Oisplay_Channel 

<Di splay_Fore(plot?) > 


rsb_stotus_f i Iter - 

RADAR-CONFI DURATION-POOL 
To_Correlot ion 
Toi-Di  spl  ay 


(To_Correlat ion  ^  RSB*on^  plot?.Plot_Statue»PREFERRED) 

V 

(To_Correlation  ^  RSB*on*  plot?.Plot_Status-SUPPLEriENTRRY 
^  rsb_stat us? . Suppl eeent ary_Stat  us-ENRBLED) 

V 

(To_Display  /s  noti.RSB-on)/',  plot ? , PI ot_St at us*PREFERRED) 

V 

(To_Display  a  not(RSB-on)^  plot ?. PI ot_Status*SUPPLE(1ENTARV 
^  rsb-st at  us?. Suppl eeentary-St at us-ENABLED) 

■  here 

x?  £  plot?.Rsb_id.Rsb_X 
y?  *  plot?.Rsb_id.Rsb_V 
rsb_status?  S  RSB_Status(x?,y?) 

RSB  6  rsb_status?.Status_of_RSB 
on  s  DATR-REQUIREO 


Note:  Display_for»  converts  the  plot  to  a  form  that  can  be  put  on  the 
display  buffer.  In  the  original  PDL,  a  plot  is  also  put  on  the  display 
buffer  if  an  attempt  to  put  it  on  the  correlation  buffer  fails  because 
the  buffer  is  full:  that  possibility  is  not  considered  here. 

RSB-FILTER  A  cal culate_rsb  »  rsb_status_1  'ter. 

3.6.8  WEATHER.FILTER 

The  first  part  decides  if  the  weather  data  is  needed  and  adjusts  the 
values  if  necessary.  The  second  part  sends  the  data,  after  setting  a 
display  rate  parameter,  to  the  display  buffer. 

•eather_f i Iter - 

RAOAR-CONFIGURATI ON-POOL 
p1ot?,plotl  :RA0RR_PL0T 
»d:STATION_DATR 


\ 
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p 1 ot ? . S i t e_Dat a  <  ran  Ueother_Data 
ad  €  St  at i on_Dat a 

sd , Radar_I D*»eat her? . Rece i w i ng_Radar_I D 
•eather? .Start-Range  i  lieit? 

(•eat  her?. Stop-Range  i  1 ieit?)v(«eother|.Stop_Range*l  ieit?) 
•here  «eat her?8Ueather_0at  o''(  pi  ot  ? .  S  i  t  e_Dat  a ) 

•eather  |8Ueather_Data''(p1ot!.Site_0at  a) 
•ask?8»eather?.flzi»uth  diu  126  ♦  1 
1  i  eit?8(sd.Uealher_flask(eask?) )  .Lie it  i  ng_Range 


•eather_dieplay - 

RRDRR-CONFIGURRT ION-POOL 

To_Disploy 

plot!  : RRORR-PLOT 

sd:STRT10lt_DRTR 

SVSTEn_PRRRf1ETERS2 


plot?.Site_Data  t  ran  Ueather_Oata 
sd  c  Station-Data 

sd.Radar_ID*»eather?.Receiuing_Radar_ID 

plot!. Oecay_T i »e“NO_CVCLE_TO_DISPLRV*sd . S»eep_T i »e 

To_Di splay 

•here  ■eather?sUeather_Data',(plot? .  S  i  te_Dat  a) 


UERTHER-FILTER8  «eat her_f i 1  ter  »  »eather_display 


3.7  The  Radar  Processing 

Finally  the  radar  processing  activity  is  specified  in  terms  of  the 
above  operations  by  the  schema  expression:- 

RRORR-PROCESSING  8 

(TRICE  and  TARGET)  »  TIt1E_STfl!1P  >  REGISTRRTIOH-COLLIURTION  » 
R-RZ-FILTER  >  COORO-COHUERT  »  RSB-FILTER 
or 

(TRICE  and  not  TARGET)  >  UERTHER-FILTER. 
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DOCUWDT  CONTROL  SHttT 


Ovcri'l  security  classification  of  thotl 


UNCLASSIFIED 


(if  fir  as  oo s s i 1 1 e  this  shaft  ohould  contain  only  unclassified  inforaalisn.  If  it  is  naccssanr  * ;  t n‘f 
classified  inforoation,  the  boi  concerned  aust  be  aarked  to  Indicate  the  classification  eg  (P)  (C)  or  {$!  ) 
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Code  (if  knoun) 
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SYSTEMS,  1 
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7c.  Presented  at  (for  conference  oarers)  Title,  place  and  date  of  conference 
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10.  Date 
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VP 
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13.  Project 
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IS.  Distribution  stateeent 
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Abstract  This  report  describes  an  initial  investigation  into  the  formal  specif icaticji 
language  Z  and  its  applicability  to  Air  Traffic  Control  Systems.  The  software 
|corresponding  to  the  initial  radar  plot  processing  in  the  multi-radar  automatic 
tracking  system  at  the  London  Air  Traffic  Control  Centre  (LATCC)  was  used  in  the 
investigation.  An  informal  pseudo  code  description  of  the  radar  plot  processing 
function  was  taken  as  the  'requirements’  and  converted  into  a  formal  spec  if  icatiotj 
in  the  Z  language.  The  specification  was  partly  validated  using  an  RSRE  Z  syntax 
and  type  checking  tool.  The  experiences  gained  during  the  exercise  are  discussed 
and  potential  benefits  for  the  Civil  Aviation  Authority  are  highlighted... 
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